binjr on the AUR (Arch User Repository) about binjr HOT 15 OPEN

Also, I updated the sig verification in binjr so that it recognize either of the two keys, so we once we consider that enough time has passed that most people had a chance to update to a version that knows about the new key on older versions, we can start signing releases it and hopefully limit breakage to a minimum.
Again, I should I've done that 3 years ago...

from binjr.

3 years is nothing for a program like binjr people will still be using in 100 ;-)

The issue with yay is unrelated to the keys you provide, as it fetches them from key servers using the provided fingerprints. Not only that, but when provided with two fingerprints, it actually ends up fetching both keys — you just have to run it twice. It's supposed to handle that in one go, though, so that may as well be an issue with the key servers themselves.

Nevertheless, the change you've done definitely looks like an improvement to me.

from binjr.

Yes there is: you can add --disable-update-check as cmd line argument in the bootstrap script.

from binjr.

Hey @Arkanosis, this looks great; thanks for taking the time to do this!

Now, with regard to PGP signatures, it is all a bit of a mess, I'm afraid:

BAF5C2D20BE017155EE108152065AD47B326EB92 (“Frederic Thevenet”) is currently used to sign both:

• Artifacts uploaded to Maven central (https://search.maven.org/search?q=eu.binjr)
• Packages available from the github release page (or the download page of the website with basically serves the same content).

Meanwhile, 20CAEC83151CCC7CE12DF29EAF45EEEFB23702CB (“binjr (Package signing key)” is used to sign packages available from:

• The RPM repo (https://repos.binjr.eu/rpm/)
• The APT repo (https://repos.binjr.eu/apt/)

So the short answer to your question is that if you're distributing the linux tar.gz based package for github release, then yes, the only key involved is BAF5C2D20BE017155EE108152065AD47B326EB92 (“Frederic Thevenet”)

As for the long answer - and the reason behind the apparent madness - when I started, I opted to create a specific sub-key attached to my own master key to do all the required signing, but when I came round to making RPM and APT repos years later, it turned out that one of these (maybe both) did not support sub-keys for signing artifacts, so I had to create a new master key for that sole purpose: 20CAEC83151CCC7CE12DF29EAF45EEEFB23702CB (“binjr (Package signing key)” )

Now, I considered using this new key for singing the other packages, but then I realized that because the code used to update the app from itself (for Windows and Linux) used the key (more exactly the fingerprint, as the public key itself is downloaded from the website) to verify that the binaries downloaded for the update was genuine.
It was therefore not straightforward to changes it because an old version of the app with no knowledge of the new key would have no way to verify the update that contained the new key and verification code, etc... It's probably not an unsolvable problem, but as I said it's not straightforward so I decided to leave it be for the time being and to come back to it later on... I think this was maybe 3 year ago.... 🤷

I still would like to go back to a single key at some point (in hindsight, if I'd baked support for the new key back then it would certainly be quite safe to pull the plug on the old key by now...) so it would be wise to make sure whatever we do for this new distribution channel does not further tie us up further.

from binjr.

Hi @fthevenet , thanks for the feedback!

That makes sense now, and I remember you already talked about the backward compatibility issue before.

I don't think the current situation is very worrying when it comes to the AUR, as the package maintainers can always update the key fingerprint if needed (ie. there's no breaking backward compatibility issue). That wouldn't be completely transparent either, though: depending on how the users retrieve the package from the AUR, that would cost them a manual retrieval of the new key or just being prompted to accept the new key (when using a tool like yay), which is more a problem of trust than of a completely broken package.

That being said, another signature file next to the already existing one would be enough to “fix” the situation, so that may be worth doing… Ie. the legacy signature with the old name for the auto-updater and the new signature with a new name for the AUR and slowly transitioning the auto-updater over multiple releases. I just like the current signature file name, so I don't know :)

from binjr.

Actually, I may know why the tool you're using is only picking up the first key listed in https://binjr.eu/openpgpkey/binjr_dev_keys_keys.asc : I built that file by concatenating two -----BEGIN/END PGP PUBLIC KEY BLOCK---- manually (I've seen that done elsewhere, and gpg --import never seemed to have any trouble finding both keys in it.
But I just realized now that some implementation (i.e. the BouncyCastle Java lib) will only pick-up the first key from such files; in order for it to get all keys, you must combine them all in a single ASCII armor block. gpg --export --armor will do that for you if you give it the list of keys to export.
I re-exported binjr public keys in such a format here: https://binjr.eu/openpgpkey/binjr_dev_combined_keys.asc; could you please see if that helps in you case?

from binjr.

Just one question; does yay take care of updating packages it deploys?
If yes, isn't there a chance that it conflicts with the built-in update system in binjr's linux tar.gz bundle?

from binjr.

On the topic of separating the distribution of the app itself and its runtime (the JDK); I have mixed feelings about that one, because while I deeply feel like it is a terrible waste to distribute a copy of the same runtime with very single app (be it the jvm, electron or whatever else), the reality is that for desktop apps it effectively solves a lot of problems, albeit in a very kludgy way...

The main problem here, is that you could split the runtime dependency from the rest fairly easily; but in fact you would achieve fairly little, I'm afraid; you'd save a handful of MiB when downloading the app bundle but no more than 20 to 30, I think, because the embedded runtime is already stripped from the modules it doesn't need to run this specific app.
Which means, by the way, that if binjr is the only app on your machine that requires a Java runtime, you'd end up having to DL a full copy of it (~170 MiB) and it would use more disk space and bandwidth overall.

The other important aspect is course keeping an up-to-date copy of the runtime for security reasons. This is a very valid point, and I'd forgive anyone for not trusting me with keeping up-to-date with binjr releases (because I wouldn't trust me either if I didn't know myself. And even then, I still don't know than I would 😛).
But to be honest, the runtime only represents a fraction of the vulnerable surface of the app, and keeping in mind the log4shell fiasco as only the most recent example, the rest of the dependencies are as ripe with gaping holes as the main engine. And I'm not even talking about my own code, God forbid!

So that naturally takes us down the rabbit hole of pulling each Java librairies as separate packages so that the user can reclaim the responsibility of updating those too; this is after all how things are supposed to work with native libs, at least under a catered Linux distro. But the really is that the Java world uses - mostly - Maven central to distribute dependencies and AFAIK you'd be hard pressed to find debs or rpms of, says, log4j, lucene etc... from reliable and trustworthy sources, so that's a dead end anyway.

And then, there's the matter of making sure that all of these moving parts remains compatible with each other... Which is what maintainers do when shipping a release, so that users don't have to!

The silver lining (or the self-delusion, you choose!) to this story, is that binjr is open source after all, and fairly easy to build even if you're not a Java expert, so at the end of the day if someone needs to update parts of it, being the runtime or third party libs, it's easy enough to fork it and/or make a pull request, I guess.

from binjr.

Just one question; does yay take care of updating packages it deploys?
If yes, isn't there a chance that it conflicts with the built-in update system in binjr's linux tar.gz bundle?

Yes, it's basically an equivalent of apt or yum, which will get the latest version and install / update it where root rights are required to write (/opt and /usr/bin ATM).

So you're right that there's an overlap with the built-in update system, and we probably want to disable it (it won't be able to update anyway, since binjr is not supposed to run as root). Isn't there already a way to disable the builtin update system, used in .deb and .rpm packages?

from binjr.

There is also an option named --packaging=XXXX where you can tell the app how it is supposed to have been packaged so that it knows how to behave based on that info.
Accepted values are:

If you pass --packaging=UNKNOWN (or --packaging=LINUX_RPM, --packaging=LINUX_DEB, etc...) it will automatically check for a new version, and display a notification to the end-user, but it won't try and download and install it:

If you think this is the behaviour you want, I'd be happy to add a LINUX_AUR to the list, so that it looks nicer if anything else.

from binjr.

On the topic of separating the distribution of the app itself and its runtime (the JDK); I have mixed feelings about that one

Yeah, same here, TBH. I'd stick to whatever the distro prefers, but in the case of Arch, there's no consensus among maintainers, so I guess it's up to the maintainers of a specific package to decide, I guess.

All your points make perfect sense (thanks for the detailed arguments!) and while I'd still weight the options on a distro like Debian or NixOS, I'm now even less inclined to split the upstream binjr packaging on Arch.

And then, there's the matter of making sure that all of these moving parts remains compatible with each other... Which is what maintainers do when shipping a release, so that users don't have to!

This for me is the main reason why splitting is a hard task. Debian does it the hard way (log4j, lucene 😉), but it means they have to check everything still works together every time a new version of the OS is released, which only works when you release only once every few years. The benefit then, is that you can have security upgrades for many years without compromising with stability.

Let's forget about splitting on Arch then. I don't feel like there is any clear benefit to expect there, at least as long as binjr is actively maintained like it is today.

from binjr.

Oh, I thought I had replied to this, but obviously I haven't…

There is also an option named --packaging=XXXX where you can tell the app how it is supposed to have been packaged so that it knows how to behave based on that info.
[…]
If you think this is the behaviour you want, I'd be happy to add a LINUX_AUR to the list, so that it looks nicer if anything else.

Yeah, that would be nice to have a similar behavior regardless of the package manager. We could make use of this option for binjr-bin and binjr-src. As for for binjr-git, I feel like --disable-update-check would make more sense, but I'm actually not sure…

from binjr.