Push binaries to downstream distros

[droidmonkey]

Need to figure out the process for overtaking binary distribution for keepassx on upstream. May start with a ppa or similar.

[nutritiousreject]

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

[zokier]

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.

[Mte90]

Will be amazing in debian https://packages.qa.debian.org/k/keepassx.html

[phoerious]

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.

[daniellandau]

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.

[Gerii]

A PPA would be nice for Ubuntu users. Has anyone experience with maintaining one?

[droidmonkey]

I created a PPA, great idea!

https://launchpad.net/~droidmonkey/+archive/ubuntu/keepassx-reboot

[Gerii]

Nice, thanks!

[george-viaud]

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:

A PPA would be nice for Ubuntu users. Has anyone experience with maintaining one?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassx/issues/5#issuecomment-250973911, or mute the thread https://github.com/notifications/unsubscribe-auth/APzGhvJ826wVStoTJVKgparoVdeVn5-Sks5qv783gaJpZM4KK_b4.

[phoerious]

The binary could be signed with some "official" GPG key whose public key is pushed to the source Git repository.

[droidmonkey]

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?

[george-viaud]

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 Sent: Oct 2, 2016 10:32 AM To: keepassxreboot/keepassx Cc: George Viaud; Mention Subject: Re: [keepassxreboot/keepassx] Push new binaries to upstream distros (#5)

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. Reply to this email directly, view it on GitHubhttps://github.com/keepassxreboot/keepassx/issues/5#issuecomment-250983536, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APzGhqsWhJSpOh1qF_clLcr64ig-VLqKks5qv-rDgaJpZM4KK_b4.

[george-viaud]

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 Sent: Oct 2, 2016 10:18 AM To: keepassxreboot/keepassx Cc: George Viaud; Comment Subject: Re: [keepassxreboot/keepassx] Push new binaries to upstream distros (#5)

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. Reply to this email directly, view it on GitHubhttps://github.com/keepassxreboot/keepassx/issues/5#issuecomment-250982759, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APzGhswQFgepA4C1o25ZJepstQ39bEctks5qv-dWgaJpZM4KK_b4.

[timeraider4u]

@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.

[droidmonkey]

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.

[Maxqia]

@daniellandau grumbles angrily https://aur.archlinux.org/pkgbase/keepassx-http, now how are we going to merge :(

[daniellandau]

@Maxqia I added you as co-maintainer to the AUR package.

[Maxqia]

@daniellandau Merged the git side of things, now waiting for the package to be merged ;)

[ghost]

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!

[bms]

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.

[ghtux]

https://aur.archlinux.org/packages/keepassx-reboot-git/

So this will be the "official" maintained AUR repo? Already using that, just to be sure :-)

[TheZ3ro]

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)

[daniellandau]

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.

[TheZ3ro]

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

[ghost]

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.

https://bugs.gentoo.org/show_bug.cgi?id=598601

[TheZ3ro]

Nice! @lebarondemerde

[TheZ3ro]

Any news on binary distribution for the following platform?

• Debian - @Mte90 (unavailable)
• Ubuntu - @droidmonkey (info on the PPA? can we made it a team PPA instead of your personal? )
• Fedora (unavailable, make a request here https://rpmfusion.org/Wishlist)
• Archlinux - @daniellandau (this seems working and ok)
• Gentoo - @lebarondemerde (info on the ebuild?)

Thanks

[ghost]

Gentoo, not on tree yet.

We have the live (git version) ebuild on bugs, what is ok for the majority of Gentoo users, and I believe when the 2.10 be out some dev should push it to the tree.

[droidmonkey]

I'll gen up a team ppa and snap for Ubuntu. I'm a Fedora user as well and will investigate that avenue.

[TheZ3ro]

I need this information for the Download page in the website. https://github.com/keepassxreboot/keepassxc_site/tree/develop

Demo screenshot

OT: @droidmonkey I will send you an email soon.

[ghost]

The live ebuild can be found here, but this is not a official one until it enter in the Portage tree.

Also, it will grab the latest code on git when you compile it.

[TheZ3ro]

@lebarondemerde thanks I will fix it with the next commit on the site repository

[tofra]

Anyone able to create a binary for Mac?

[samrocketman]

Correction in title. Distros are typically referred to as being downstream from original application sources.

[droidmonkey]

You are correct, sir. I have changed the title 👍

[mongrelion]

We need a consistent and easy way to be able to reproduce the build steps for generating packages for the different platforms and flavours (Archlinux, Debian, Ubuntu, Fedora, FreeBSD, macOS, Windows), which could also lead us to an automated way of delivering packages. I'm thinking that this would be a great use case for both Docker and TravisCI. I would like to start with generating the DMG package for macOS (this is what I run on my laptop) but I'm failing hard at it. It seems like the wiki might be out of date: https://github.com/keepassxreboot/keepassxc/wiki/Install-Instruction-from-Source#packaging It talks about a package task which I can't seem to find anywhere in the code base. If I could get some help on this that would be great! So far I have got a Docker image that installs all the build dependencies in Ubuntu and when I build the project I get only warnings but the build passes!

[TheZ3ro]

We already have TravisCI working, we have an opened Issue for making travis deploy the binaries on github. Take a look at this Issue https://github.com/keepassxreboot/keepassxc/issues/48

The wiki is perfectly up-to-date

The make package command for macOS is declared here: /src/CMakeLists.txt#L241-L247 and uses CMake's CPack

[ghost]

On FreeBSD the packages are built from its Port version (of the Ports tree) from time to time, with the compile time options (if any) the developer who maintain the Port feel should be the default ones.

I was already "announced" it on FreeBSD forum but still not opened a bug report on the bug tracker. I am not too prolific on FreeBSD yet.

https://forums.freebsd.org/threads/58443/#post-334668

You who know the project well may want to contact the keepass (and variations) port maintainers to find out if he/she want to also maintain the KeePassXC:

https://www.freebsd.org/cgi/ports.cgi?query=keepass&stype=all&sektion=all

Cheers!

[mongrelion]

@TheZ3ro Cmake it's completely alien to me, so, thanks for the clarification. I am Currently running Mac OS and I'm interested in building a binary from a Docker container running Linux (Ubuntu, specifically). If there is any documentation on the cross compiling I would appreciate being pointed towards that. If not, any help that can lead me towards a successful cross compilation would be highly appreciated.

Cheers

[ghost]

The KeePassXC is now on a (user) Gentoo Overlay:

https://github.com/krivenko/gentoo-overlay/blob/master/app-admin/keepassxc/keepassxc-9999.ebuild

About Overlays: https://wiki.gentoo.org/wiki/Overlay

[RealOrangeOne]

The problem with users uploading things to their distros package managers, is it's possible to end up with either duplicated or out-of-date packages. Eg on the AUR there are currently 2 packages, both give the same version, both build from source, but 1 is actually newer. if #48 can be implemented properly, this should solve this issue. Would be nice if org members had control over the packages, means i'd personally trust the packages more.

[phoerious]

Two packages on AUR is intended. One is stable, the other is the current Git develop branch. 

[ghost]

@RealOrangeOne Yes, I agree completely but while a dev do not began to maintain the package on the official Portage tree, everyone can use the software already, specially because ebuilds are not something simple to write.

[northway]

What's latest on Ubuntu? The method is finalized just need someone to maintain is?

[phoerious]

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. 

[northway]

We have a public repository just need someone to maintain it, like putting out the latest versions, signing them etc ... ?

[phoerious]

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.

[northway]

It's from Ubuntu wiki:

Ubuntu regularly incorporates source packages from Debian, so it is encouraged to upload a package to Debian first to automatically have it in Ubuntu in due time. In addition to that your package will reach a much broader audience if it is in Debian and all of its derivatives.

In order to have faster reviews, several teams have been set up to manage a given subset of packages.

After some search, in nutshells the process would be like this:

• Create a proper .deb package. - http://packaging.ubuntu.com/html/
• Present the package in proper forum, so that the debian folks could review it. Package forums
• If they accept it, it will appear in all Debian derivatives and later Ubuntu automatically import it to theirs.

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

[phoerious]

Thanks. We can create a deb automatically as part of our release procedure.

[ghost]

KeePassXC is now on official Gentoo Portage tree.