Red Hat Bugzilla – Bug 996813
Review Request: SQLCipher - Encrypted SQLite databases
Last modified: 2016-03-10 05:02:58 EST
This is my first package review request, so I'll be needing a sponsor if possible. I've based this package of the latest sqlite package sources for Fedora 19. Spec URL: https://github.com/abeluck/fedora-sqlcipher/raw/master/sqlcipher.spec SRPM URL: https://github.com/abeluck/fedora-sqlcipher/raw/bins/sqlcipher-2.2.1-1.fc18.src.rpm Description: SQLCipher is a C library that implements an encryption in the SQLite 3 database engine. Programs that link with the SQLCipher library can have SQL database access without running a separate RDBMS process. It allows one to have per-database or page-by-page encryption using AES-256 from Open SQLCipher has a small footprint and great performance so it’s ideal for protecting embedded application databases and is well suited for mobile development. * as little as 5-15% overhead for encryption * 100% of data in the database file is encrypted * Uses good security practices (CBC mode, key derivation) * Zero-configuration and application level cryptography * Algorithms provided by the peer reviewed OpenSSL crypto library. SQLCipher has broad platform support for with C/C++, Obj-C, QT, Win32/.NET, Java, Python, Ruby, Linux, Mac OS X, iPhone/iOS, Android, Xamarin.iOS, and Xamarin.Android. Fedora Account System Username: abelxluck Output of rpmlint: $ rpmlint SPECS/sqlcipher.spec RPMS/x86_64/sqlcipher-* SRPMS/sqlcipher-2.2.1-1.fc18.src.rpm sqlcipher.x86_64: W: spelling-error %description -l en_US crypto -> crypt, crypts, crypt o sqlcipher.x86_64: W: spelling-error %description -l en_US iOS -> OS, SOS, DOS sqlcipher-devel.x86_64: W: spelling-error Summary(en_US) embeddable -> embedded sqlcipher-devel.x86_64: W: no-documentation sqlcipher-tcl.x86_64: W: spelling-error Summary(en_US) embeddable -> embedded sqlcipher-tcl.x86_64: W: no-documentation sqlcipher.src: W: spelling-error %description -l en_US crypto -> crypt, crypts, crypt o sqlcipher.src: W: spelling-error %description -l en_US iOS -> OS, SOS, DOS 5 packages and 1 specfiles checked; 0 errors, 8 warnings. Link to successful koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5813236
Are you going to support EPEL?
Hm, I hadn't thought to. This would be my first time maintaining a package. Is the package more likely to be accepted if I support EPEL? I'd need to look into the workload required to support it.
That usually has no affect whether you want to build for EPEL or not. The _real_ problem here is: Your package ships a bundled sqlite-version and that's something which is strongly discouraged. See: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries You should actually unbundle `sqlite` and build this against the one shipped by the system's libs. BTW. Christopher's question was about the presence of `rm -rf %{buildroot}` on %install and %check and the presence of Group: and BuildRoot: tags... Those are simply not needed, but for <= el5. You can safely drop `defattr`, because this was needed on <= el4.
The next problem related to the bundled `sqlite` is: They way it get's packaged will simply conflict with system's installation of sqlite and thus is another no-go and will cause _serious_ trouble to other software which is build against system's version of sqlite..
Thanks Björn! 1. I believe SQLCipher deserves a No Bundled Libraries exception, so I'm preparing an exception request. Once that's submitted, I'll link it here. 2. The reason for the EPEL looking code is because I based this package off the existing sqlite package. Should I remove them if I don't plan on supporting EPEL? 3. I don't believe SQLCipher will conflict with the system's sqlite. There are no file path conflicts. Moreover, I have sqlite, sqlite-devel, sqlcipher, and sqlcipher-devel installed simultaneously on my dev system with no conflicts. 4. A new version of SQLCipher has been released since I created the package, I'll be updating it next week. Now that I have a space on fedorapeople.org, I'll upload the new sources there. You can see this from the rpmls output below. [user@fedora-pkg rpmbuild]$ rpmls RPMS/x86_64/sqlcipher-devel-2.2.1-1.fc18.x86_64.rpm -rw-r--r-- /usr/include/sqlcipher/sqlite3.h -rw-r--r-- /usr/include/sqlcipher/sqlite3ext.h lrwxrwxrwx /usr/lib64/libsqlcipher.so -rw-r--r-- /usr/lib64/pkgconfig/sqlcipher.pc [user@fedora-pkg rpmbuild]$ rpmls RPMS/x86_64/sqlcipher-2.2.1-1.fc18.x86_64.rpm -rwxr-xr-x /usr/bin/sqlcipher lrwxrwxrwx /usr/lib64/libsqlcipher.so.0 -rwxr-xr-x /usr/lib64/libsqlcipher.so.0.8.6 drwxr-xr-x /usr/share/doc/sqlcipher-2.2.1 -rw-r--r-- /usr/share/doc/sqlcipher-2.2.1/LICENSE -rw-r--r-- /usr/share/doc/sqlcipher-2.2.1/README -rw-r--r-- /usr/share/man/man1/sqlcipher.1.gz [user@fedora-pkg rpmbuild]$ rpmls RPMS/x86_64/sqlcipher-tcl-2.2.1-1.fc18.x86_64.rpm drwxr-xr-x /usr/lib64/tcl8.5/sqlcipher -rwxr-xr-x /usr/lib64/tcl8.5/sqlcipher/libtclsqlite3.so -rw-r--r-- /usr/lib64/tcl8.5/sqlcipher/pkgIndex.tcl
Any news here?
definitely missing in the repo,no one willing to back it ?
Closing due long inactivity. Feel free to reopen if you want to continue.
*** This bug has been marked as a duplicate of bug 1310294 ***