4 ms·

It's very annoying when the applications use sqlite with encryption. That is not open source, so regular language bindings can not be used.

TheRealPomax 6y ago
I'm not sure how slqite as your application file format has anything to do with open source, honestly. It's certainly super easy for open source projects to use, but a closed source proprietary application using an encrypted sqlite file sounds perfectly sensible to me? We all win when folks decide to leave it accessible, but I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software.
- cfn 6y ago
  I guess he/she meant that the extension that encrypts the database is proprietary. I believe that was the only option for a while but now there is an open source alternative.
  - yellowapple 6y ago
    Is the open-source alternative bidirectionally interoperable with the closed-source version (i.e. it can decrypt the proprietary encryption and the proprietary version can decrypt the FOSS version)? If so, then that's handy.
    - justinclift 6y ago
      The "officially blessed" (my wording) encryption for SQLite is SEE (proprietary): https://www.sqlite.org/see/doc/release/www/index.wiki https://www.sqlite.org/see/doc/release/www/index.wiki There are third party encryption approaches for SQLite. One of the most popular is SQLCipher: https://github.com/sqlcipher/sqlcipher/ https://github.com/sqlcipher/sqlcipher/ Those two don't have compatible file formats. eg no interoperability Not sure if any others do, but yeah it would be handy if there are.
- wrigby 6y ago
  It looks like the actual library to read/write an encrypted SQLite DB is licensed separately from the open source SQLite[1], so even if you have the encryption key, you can't access the encrypted format: 1: https://www.sqlite.org/see/doc/release/www/readme.wiki https://www.sqlite.org/see/doc/release/www/readme.wiki
- labawi 6y ago
  > I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software. I think I'd mostly disagree. Selling an application is one thing, but the data itself is usually customers' and holding their data hostage is not a proper thing to do.
  - TheRealPomax 6y ago
    That's a tenuous argument at best, heavily relying on the application in question not offering any way to export your data, which many applications do come with. Just because the file format is locked, doesn't mean the data in it is locked. You just need the application to unlock it.
    - samatman 6y ago
      This is self contradictory. Listen to what you're saying: the data isn't locked, you just need the... application, to... unlock it. That's beyond tenuous, it's invalid.
      - brigandish 6y ago
        You can say it's invalid but it's the fact of the matter, the reality, and since the data in question is only in the app because the owner of the data has access to the app it means that the data is not locked away from the owner, because they have access to the export function.
      - TheRealPomax 6y ago
        Almost as if different clauses can impart different context to the same word. The data is not locked, provided you have the application that manages that data. If you want to call it "locked" then "the application itself turns it into unlocked data for you". That argument that a proprietary file format "locks" data ignores the fact that it's the pair {application, file} that determines whether your data is locked away or not. For instance: Microsoft Word data? not locked. You can trivially export it in quite a lot of ways. Can you easily get it from a traditional .doc file? Hell no, but that doesn't mean the data itself is inaccessible. Instead of using sqlite, or xslt, or PERL, or whatever, you use word.

TheRealPomax 6y ago

I'm not sure how slqite as your application file format has anything to do with open source, honestly. It's certainly super easy for open source projects to use, but a closed source proprietary application using an encrypted sqlite file sounds perfectly sensible to me? We all win when folks decide to leave it accessible, but I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software.

cfn 6y ago
I guess he/she meant that the extension that encrypts the database is proprietary. I believe that was the only option for a while but now there is an open source alternative.
- yellowapple 6y ago
  Is the open-source alternative bidirectionally interoperable with the closed-source version (i.e. it can decrypt the proprietary encryption and the proprietary version can decrypt the FOSS version)? If so, then that's handy.
  - justinclift 6y ago
    The "officially blessed" (my wording) encryption for SQLite is SEE (proprietary): https://www.sqlite.org/see/doc/release/www/index.wiki https://www.sqlite.org/see/doc/release/www/index.wiki There are third party encryption approaches for SQLite. One of the most popular is SQLCipher: https://github.com/sqlcipher/sqlcipher/ https://github.com/sqlcipher/sqlcipher/ Those two don't have compatible file formats. eg no interoperability Not sure if any others do, but yeah it would be handy if there are.
wrigby 6y ago
It looks like the actual library to read/write an encrypted SQLite DB is licensed separately from the open source SQLite[1], so even if you have the encryption key, you can't access the encrypted format: 1: https://www.sqlite.org/see/doc/release/www/readme.wiki https://www.sqlite.org/see/doc/release/www/readme.wiki
labawi 6y ago
> I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software. I think I'd mostly disagree. Selling an application is one thing, but the data itself is usually customers' and holding their data hostage is not a proper thing to do.
- TheRealPomax 6y ago
  That's a tenuous argument at best, heavily relying on the application in question not offering any way to export your data, which many applications do come with. Just because the file format is locked, doesn't mean the data in it is locked. You just need the application to unlock it.
  - samatman 6y ago
    This is self contradictory. Listen to what you're saying: the data isn't locked, you just need the... application, to... unlock it. That's beyond tenuous, it's invalid.
    - brigandish 6y ago
      You can say it's invalid but it's the fact of the matter, the reality, and since the data in question is only in the app because the owner of the data has access to the app it means that the data is not locked away from the owner, because they have access to the export function.
    - TheRealPomax 6y ago
      Almost as if different clauses can impart different context to the same word. The data is not locked, provided you have the application that manages that data. If you want to call it "locked" then "the application itself turns it into unlocked data for you". That argument that a proprietary file format "locks" data ignores the fact that it's the pair {application, file} that determines whether your data is locked away or not. For instance: Microsoft Word data? not locked. You can trivially export it in quite a lot of ways. Can you easily get it from a traditional .doc file? Hell no, but that doesn't mean the data itself is inaccessible. Instead of using sqlite, or xslt, or PERL, or whatever, you use word.