Push binaries to downstream distros #5
Comments
|
https://wiki.archlinux.org/index.php/creating_packages#Creating_a_PKGBUILD Not looking to maintain this packages repo, But submitting packages to the AUR is pretty easy |
|
For Arch Linux specifically, there are already several versions of keepassx on AUR based on various github forks. Best option in my opinion would be to merge those forks and then attempt to enlist the maintainers to join forces in packaging. |
|
Will be amazing in debian https://packages.qa.debian.org/k/keepassx.html |
|
If nobody else volunteers, I would take responsibility for the AUR package, but if someone else wants to do it, I'd be glad. I'm always open for supporting in this regard, though. |
|
I went ahead and made the AUR package: https://aur.archlinux.org/packages/keepassx-reboot-git/ I started maintaining my personal fork a while back when I couldn't get my trivial usability fix merged (or commented on or acknowledged in any way) upstream. I also rebased a couple of pull requests by others, I'll send them too as pull requests here. |
|
A PPA would be nice for Ubuntu users. Has anyone experience with maintaining one? |
|
I created a PPA, great idea! https://launchpad.net/~droidmonkey/+archive/ubuntu/keepassx-reboot |
|
Nice, thanks! |
|
PPA for source files or binaries? I strongly advise against using a piece of open source security software pre-compiled from a PPA. Would be better to get it from source and build yourself - otherwise too much funny stuff can be done in the binary and nobody would know. "Trust but Verify" On 10/02/2016 07:27 AM, Gerald P. wrote:
|
|
The binary could be signed with some "official" GPG key whose public key is pushed to the source Git repository. |
|
Agree with @george-viaud I am very security conscious. Any push from the ppa will be signed with the GPG I used to register with launchpad. Public keys/fingerprints should be posted to the README or SECURITY files for future use in validation. Seem reasonable? |
|
It helps but there is no way to guarantee the bins themselves were not intentionally or inadvertantly compromised. Dane with the keys if they became compromised, no? Compiling from sources which are publicly scrutinised is really the best we have. Perhaps focus on making the build process as turn key as possible, and then from within the repo itself? Perhaps a .sh or similar? Just my 2 cents of course. From: Jonathan notifications@github.com Agree with @george-viaudhttps://github.com/george-viaud I am very security conscious. Any push from the ppa will be signed with the GPG I used to register with launchpad. Public keys/fingerprints should be posted to the README or SECURITY files for future use in validation. Seem reasonable? You are receiving this because you were mentioned. |
|
That just guarantees that the binary posted matches the one references by the hash. Not that it was compiled from the untainted source. From: Janek Bevendorff notifications@github.com The binary could be signed with some "official" GPG key whose public key is pushed to the source Git repository. You are receiving this because you commented. |
|
@george-viaud: Yes, compiling from source (like in Gentoo Linux) leads to an increase in trust. But normal end-users will not want to compile anything from source at all. They just want to use their favourite password-manager like they would do on Windows by installing a binary package. But I think with Debian/Ubuntu systems it is possible to create packages for both, source and binary distribution. |
|
The beauty of open source is you have the OPTION of compiling it by source ;-) The process is very turn key using cmake build tool. This issue has strayed a bit off message, fyi. |
|
@daniellandau grumbles angrily https://aur.archlinux.org/pkgbase/keepassx-http, now how are we going to merge :( |
|
@Maxqia I added you as co-maintainer to the AUR package. |
|
@daniellandau Merged the git side of things, now waiting for the package to be merged ;) |
|
Not binary but, Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=598601 Is KeePassX-Reboot supposed to compile on FreeBSD, or there is a plan to have a native version? Cheers! |
|
I'm still trying to resurrect some of my own development, but I made a few changes to the usage of CMake to allow building KScope (another KDE application) and generating DEBs using CMake's own generator. |
|
https://aur.archlinux.org/packages/keepassx-reboot-git/ So this will be the "official" maintained AUR repo? Already using that, just to be sure :-) |
|
I think there will be no "official" AUR repo unless a KeePassXC maintainer keep it updated. That repo is maintained by @daniellandau but unfortunately is not updated to the 2.0.3 release and with the new project name. When we release the 2.1.0 version we will address this issue (we are also working on AppImage and Snap) |
|
Not official by any means, but there is now https://aur.archlinux.org/packages/keepassxc-git/, which should have the comments+votes merged from the previous package soon. |
|
No problem it's free software, everybody can redistribute it. @daniellandau If you can maintain it for every release (maybe with a ping from me or another maintainer) this can be the "official" AUR repo to me |
|
KeePassXC will be coming to Gentoo. There is a ebuild for git version already on bug tracker, but I think they will wait the v2.1.0 to add it to the portage tree. |
|
Nice! @lebarondemerde |
|
What's latest on Ubuntu? The method is finalized just need someone to maintain is? |
|
We have a Snap in the store, but no official Deb yet. We can easily build one, but we also need to get it into the repository.
|
|
We have a public repository just need someone to maintain it, like putting out the latest versions, signing them etc ... ? |
|
I would prefer having it in an official repository. Using a PPA or the like is only a temporary solution. We have to see what the deadlines and requirements are for getting into the repositories of the next Ubuntu release. |
|
It's from Ubuntu wiki:
After some search, in nutshells the process would be like this:
Worth to mention, there are other ways as well. They prefer way that was mentioned above. http://askubuntu.com/questions/16446/how-to-get-my-software-into-ubuntu |
|
Thanks. We can create a deb automatically as part of our release procedure. |
|
KeePassXC is now on official Gentoo Portage tree. |
|
Awesome! First distribution to add it to their official repositories. I'll update the website later. |
|
I am starting work on an official Debian package. Looking at the thread above that should clear up some of the concerns around Ubuntu. Part of the idea behind creating a Debian package will be doing it in such a way that it is easily reproducible by others. I am aware of the packages referenced on the site but in the spirit of keeping things clean I will be creating my own from scratch using the latest released source files. If I run into any issues or if we want to discuss this further I/anyone should create a new issue specific to Debian packaging. Thanks! |
|
That sounds amazing! Thank you very much!
|
|
Might I suggest a One could create a team for contributors who are package maintainers, lock down the master branch (i.e. protect it via settings), and then can be liberal with allowing contributors r/w access to non-master branches. It also means all packaging-related issues can be created within that separate repo. Changes to master can be forced through peer review pull requests. |
|
Someone created a FreeBSD Port. Should be a matter of time to KeePassXC come to FreeBSD Ports collection. |
|
Now, it is officially on FreeBSD: https://svnweb.freebsd.org/ports?view=revision&revision=436151 |
|
I'll add it to the website in the evening. |
|
|
Closing this issue as we have substantial presence in multiple repos. Any specific issues should be opened in our distribution repository: https://github.com/keepassxreboot/keepassxc-packaging |
Need to figure out the process for overtaking binary distribution for keepassx on upstream. May start with a ppa or similar.
The text was updated successfully, but these errors were encountered: