Provide sources list with key in Deb822 format (eduvpn.sources) for easier installation (on debian based OSes) #512

Lukas-UAUX commented 2023年01月30日 11:43:30 +01:00 (Migrated from github.com)

At the moment you have to download, gpg --dearmor and store the gpg-key (for example) in /usr/share/keyrings/. Then write the sources.list, together with this path via signed-by=(possibly in addition to thearch=`) parameter in one much to long line.

With Deb822 it would be just one file to download to /etc/apt/sources.list.d/eduvpn.sources that contains the config and gpg-key already 'inline':

Types: deb
URIs: https://app.eduvpn.org/linux/deb/
Suites: stable
Components: main
Signed-by:
 -----BEGIN PGP PUBLIC KEY BLOCK-----
.
.
.
 -----END PGP PUBLIC KEY BLOCK-----

At the moment you have to download, `gpg --dearmor` and store the gpg-key (for example) in `/usr/share/keyrings/`. Then write the sources.list, together with this path via signed-by=` (possibly in addition to the `arch=`) parameter in one much to long line. With Deb822 it would be just one file to download to `/etc/apt/sources.list.d/eduvpn.sources` that contains the config and gpg-key already 'inline': ``` Types: deb URIs: https://app.eduvpn.org/linux/deb/ Suites: stable Components: main Signed-by: -----BEGIN PGP PUBLIC KEY BLOCK----- . . . -----END PGP PUBLIC KEY BLOCK----- ```

jwijenbergh commented 2023年01月30日 11:55:08 +01:00 (Migrated from github.com)

Hello Lukas, thanks for bringing this to my attention. I will look into integrating this once we release the new Go version fully

Hello Lukas, thanks for bringing this to my attention. I will look into integrating this once we release the new Go version fully

FWDekker commented 2023年02月21日 12:35:37 +01:00 (Migrated from github.com)

Interesting idea, but please take care that inline keys are a new feature: It's listed in the docs for Debian Testing, but not in the docs for Debian Bullseye. Bullseye is the latest stable Debian version, so a large amount of users do not have a system that implements this. Bullseye has security support until July 2024 and long-term support until June 2026, so I'd suggest waiting until at least late 2024, but preferably longer before implementing this.

Interesting idea, but please take care that inline keys are a new feature: It's listed in [the docs for Debian Testing](https://manpages.debian.org/testing/apt/sources.list.5.en.html), but not in [the docs for Debian Bullseye](https://manpages.debian.org/bullseye/apt/sources.list.5.en.html). Bullseye is the latest stable Debian version, so a large amount of users do not have a system that implements this. Bullseye has security support until July 2024 and long-term support until June 2026, so I'd suggest waiting until at least late 2024, but preferably longer before implementing this.

Lukas-UAUX commented 2023年02月21日 13:02:44 +01:00 (Migrated from github.com)

Ubuntu 22.04 does support this format no problem and it's derivatives probably too then. Debian is always on the slower side...

Ubuntu 22.04 does support this format no problem and it's derivatives probably too then. Debian is always on the slower side...

FWDekker commented 2023年02月21日 13:21:30 +01:00 (Migrated from github.com)

@Lukas-UAUX Ubuntu is by definition slower than Debian because Ubuntu is essentially a derivative of Debian Unstable. You might find it interesting to read about Debian Stable, Testing, and Unstable, or to read how Debian and Ubuntu are related. You're right that Debian Stable is indeed a bit (usually ~1 year) behind in terms of features (but not security updates), which is a deliberate choice to allow more extensive testing to provide a stabler system.

Many users are therefore using Debian Testing so they have access to newer features (myself included), but in general I think software (including eduVPN) should support users running older still-supported versions of operating systems (within reasonable limits). But for eduVPN, that's not up to me of course.

@Lukas-UAUX Ubuntu is by definition slower than Debian because [Ubuntu is essentially a derivative of Debian Unstable](https://wiki.ubuntu.com/DebianImportFreeze). You might find it interesting to [read about Debian Stable, Testing, and Unstable](https://www.debian.org/releases/), or to [read how Debian and Ubuntu are related](https://unix.stackexchange.com/a/28448). You're right that Debian _Stable_ is indeed a bit (usually ~1 year) behind in terms of features (but not security updates), which is a deliberate choice to allow more extensive testing to provide a stabler system. Many users are therefore using Debian Testing so they have access to newer features (myself included), but in general I think software (including eduVPN) should support users running older still-supported versions of operating systems (within reasonable limits). But for eduVPN, that's not up to me of course.

jwijenbergh commented 2023年02月21日 20:18:00 +01:00 (Migrated from github.com)

For the new version (which we will tag as 4.0 btw) we're considering dropping Ubuntu 18.04 (since it will be EOL in april) but debian 11, Ubuntu 20.04 and up will still be supported.

The main problem I have with the Deb822 format is, whilst it looks simple, there's very few documentation on whether or not this is completely ready to use and for which distributions. I was also concerned at Debian bullseye here.

If we didn't have to deal with older distros then I would have implemented gtk4 by now :).

Thanks for the great discussion and info!

For the new version (which we will tag as 4.0 btw) we're considering dropping Ubuntu 18.04 (since it will be EOL in april) but debian 11, Ubuntu 20.04 and up will still be supported. The main problem I have with the Deb822 format is, whilst it looks simple, there's very few documentation on whether or not this is completely ready to use and for which distributions. I was also concerned at Debian bullseye here. If we didn't have to deal with older distros then I would have implemented gtk4 by now :). Thanks for the great discussion and info!

Lukas-UAUX commented 2023年02月22日 09:56:40 +01:00 (Migrated from github.com)

Just to make things clear, having this file would not remove support for older distributions - but it would allow users of Ubuntu 22.04 (LTS), its descendants and for the future Debian Bookworm an easier installation and source/key management.

Just for reference the Ubuntu 22.04 Manpage: https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html

@FWDekker I know that - as you were referencing stable I was talking about it being slower then Ubuntu (when you count the non LTS releases). At home I often use Debian (testing or even sid) but for now I am on Linux Mint because Cinnamon on Debian is not really in good shape - but that is off topic ;-)

Just to make things clear, having this file would not remove support for older distributions - but it would allow users of Ubuntu 22.04 (LTS), its descendants and for the future Debian Bookworm an easier installation and source/key management. Just for reference the Ubuntu 22.04 Manpage: https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html @FWDekker I know that - as you were referencing stable I was talking about it being slower then Ubuntu (when you count the non LTS releases). At home I often use Debian (testing or even sid) but for now I am on Linux Mint because Cinnamon on Debian is not really in good shape - but that is off topic ;-)

FWDekker commented 2023年02月22日 10:46:56 +01:00 (Migrated from github.com)

I know that - as you were referencing stable I was talking about it being slower then Ubuntu (when you count the non LTS releases).

Oh like so. Yeah that makes sense :-)

Just to make things clear, having this file would not remove support for older distributions

I'm not sure if I understand you correctly then: Using Deb822 format with inline keys instead of the one-line format isn't supported by older distributions, so replacing one-line with Deb822 would remove support for older distributions, right? So perhaps you're suggesting providing both simultaneously in two separate files? In which case I'm quite sure you get errors if you define the same (uri, suite, component) tuple in multiple files.

> I know that - as you were referencing stable I was talking about it being slower then Ubuntu (when you count the non LTS releases). Oh like so. Yeah that makes sense :-) > Just to make things clear, having this file would not remove support for older distributions I'm not sure if I understand you correctly then: Using Deb822 format with inline keys instead of the one-line format isn't supported by older distributions, so _replacing_ one-line with Deb822 would remove support for older distributions, right? So perhaps you're suggesting providing both simultaneously in two separate files? In which case I'm quite sure you get errors if you define the same (uri, suite, component) tuple in multiple files.

Lukas-UAUX commented 2023年02月22日 10:56:57 +01:00 (Migrated from github.com)

At the moment no sources list is provided for downloading but these instructions: https://python-eduvpn-client.readthedocs.io/en/master/installation.html#debian-and-ubuntu

You would - completely by hand - download the gpg-keyfile, store it in /usr/share/keyrings/ and manually create a classic sources.list file/entry for that.

What I suggested was, (at least I intended to) was to also supply an complete deb822 eduvpn.sources file (next to the regular keyfile) for easier installation on more modern distros. Nothing breaks for older distros by doing that, but on newer distributions the installation is much more streamlined and easier by just downloading one file...

At the moment _no_ sources list is provided for downloading but these instructions: https://python-eduvpn-client.readthedocs.io/en/master/installation.html#debian-and-ubuntu You would - completely by hand - download the gpg-keyfile, store it in /usr/share/keyrings/ and manually create a classic sources.list file/entry for that. What I suggested was, (at least I intended to) was to _also_ supply an complete deb822 `eduvpn.sources` file (next to the regular keyfile) for easier installation on more modern distros. Nothing breaks for older distros by doing that, but on newer distributions the installation is much more streamlined and easier by just downloading one file...

FWDekker commented 2023年02月22日 11:38:41 +01:00 (Migrated from github.com)

Oh, I'd forgotten about that. I misremembered eduVPN as distributing a .deb with the list and key included, because yesterday I was looking at projects that did that, oops. Thanks for clarifying :-)

So yes, I agree that adding both options doesn't break older distros, since you should just pick the one that works for you. Which could be slightly confusing for some inexpert users who don't know which version of Ubuntu they have, maybe?

I do see one remaining issue though: other software that uses the lists. This issue is explained better in the announcement that Ubuntu 23.04 will use Deb822 by default, but basically there are other programs commonly used for building and installing packages that directly use the sources files, but they don't have full support for Deb822 yet. So users would need at least Ubuntu 23.04 (or Debian Trixie, I suppose) before they can reliably use the Deb822 format, assuming compatibility is properly achieved in the coming few months.

Basically, if you know your own system well, you can make a good judgment call on whether it's stable to use Deb822, but for most users I think that judgment call might be too complex to make, with only marginal benefit, unfortunately :-(

Oh, I'd forgotten about that. I misremembered eduVPN as distributing a `.deb` with the list and key included, because yesterday I was looking at projects that did that, oops. Thanks for clarifying :-) So yes, I agree that adding both options doesn't break older distros, since you should just pick the one that works for you. Which _could_ be slightly confusing for some inexpert users who don't know which version of Ubuntu they have, maybe? I do see one remaining issue though: other software that uses the lists. This issue is explained better in [the announcement that Ubuntu 23.04 will use Deb822 by default](https://discourse.ubuntu.com/t/spec-apt-deb822-sources-by-default/29333), but basically there are other programs commonly used for building and installing packages that directly use the sources files, but they don't have full support for Deb822 yet. So users would need at least Ubuntu 23.04 (or Debian Trixie, I suppose) before they can reliably use the Deb822 format, _assuming_ compatibility is properly achieved in the coming few months. Basically, if you know your own system well, you can make a good judgment call on whether it's stable to use Deb822, but for most users I think that judgment call might be too complex to make, with only marginal benefit, unfortunately :-(

jwijenbergh commented 2023年02月22日 14:01:28 +01:00 (Migrated from github.com)

At the moment no sources list is provided for downloading but these instructions: https://python-eduvpn-client.readthedocs.io/en/master/installation.html#debian-and-ubuntu. You would - completely by hand - download the gpg-keyfile, store it in /usr/share/keyrings/ and manually create a classic sources.list file/entry for that.

I agree that the current instructions are pretty unfriendly for the user, however, this is just little we can do to improve it. I can easily support the Deb822 format, but having separate sections for Ubuntu >= 22.04 and other, it becomes probably even more complicated to look at. Maybe it's something to look at when debian 12 releases? However that still leaves us with Ubuntu 20.04. I will not close this issue as I think it's a great suggestion though, possibly to be picked up in the future

Which could be slightly confusing for some inexpert users who don't know which version of Ubuntu they have, maybe?

I'm worried about this as well. It's also better in support e-mails to give users instructions that work on all debian based distros.

Bit off-topic, but I have been confused about this for a while.

Is there also any consensus on whether it's better to only build for the "stable/unstable" dists and point every user to it, like we do now: https://python-eduvpn-client.readthedocs.io/en/master/installation.html#debian-and-ubuntu

Or maybe do it per distro:

see the current beta instructions:

sudo apt install apt-transport-https wget lsb-release
wget -O- https://app.eduvpn.org/linux/beta/deb/eduvpn.key | gpg --dearmor | sudo tee /usr/share/keyrings/eduvpn-beta-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/eduvpn-beta-keyring.gpg] https://app.eduvpn.org/linux/beta/deb $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/eduvpn-beta.list
sudo apt-get -y update
sudo apt-get install -y eduvpn-client

(note the lsb_release -cs).

Software like signal uses xenial for everyone for some reason (click on download here https://signal.org/download/#)

The way I see it, separating it per distro would give us some control over which kind of patches we could ship for a distro, however it has the downside of having to provide many targets

> At the moment no sources list is provided for downloading but these instructions: https://python-eduvpn-client.readthedocs.io/en/master/installation.html#debian-and-ubuntu. You would - completely by hand - download the gpg-keyfile, store it in /usr/share/keyrings/ and manually create a classic sources.list file/entry for that. I agree that the current instructions are pretty unfriendly for the user, however, this is just little we can do to improve it. I can easily support the Deb822 format, but having separate sections for Ubuntu >= 22.04 and other, it becomes probably even more complicated to look at. Maybe it's something to look at when debian 12 releases? However that still leaves us with Ubuntu 20.04. I will not close this issue as I think it's a great suggestion though, possibly to be picked up in the future > Which could be slightly confusing for some inexpert users who don't know which version of Ubuntu they have, maybe? I'm worried about this as well. It's also better in support e-mails to give users instructions that work on all debian based distros. Bit off-topic, but I have been confused about this for a while. Is there also any consensus on whether it's better to only build for the "stable/unstable" dists and point every user to it, like we do now: https://python-eduvpn-client.readthedocs.io/en/master/installation.html#debian-and-ubuntu Or maybe do it per distro: see the current beta instructions: ```shell sudo apt install apt-transport-https wget lsb-release wget -O- https://app.eduvpn.org/linux/beta/deb/eduvpn.key | gpg --dearmor | sudo tee /usr/share/keyrings/eduvpn-beta-keyring.gpg >/dev/null echo "deb [signed-by=/usr/share/keyrings/eduvpn-beta-keyring.gpg] https://app.eduvpn.org/linux/beta/deb $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/eduvpn-beta.list sudo apt-get -y update sudo apt-get install -y eduvpn-client ``` (note the lsb_release -cs). Software like signal uses xenial for everyone for some reason (click on download here https://signal.org/download/#) The way I see it, separating it per distro would give us some control over which kind of patches we could ship for a distro, however it has the downside of having to provide many targets

FWDekker commented 2023年02月23日 13:35:32 +01:00 (Migrated from github.com)

Gosh, I'm not really sure about that. I don't have that much experience with setting up a repository, so take my answer with a grain of salt.

If you're not going to create separate builds for each distro, adding separate targets to your repo will at most save some users from installing patches that don't apply to them, and you should ask yourself if that's worth the effort and maintenance on your side.

If you do create separate builds and use separate targets, I suppose your advantage would be that you are less likely to have dependency conflicts, since you can have different dependency versions for different distros. (But I'm even more foreign to dependency management than I am to repository management.) Either way, this option, too, is more complex for you to manage.

In the case of Signal, from what I've read, their use of xenial basically amounts to having only a stable build, but they don't want to rename it because that would require users to change their lists, which is too much effort for what it's worth.

Looking at 3rd-party repos I'm using, there seems to be a direct correlation between the amount of money behind the project and the amount of distros they build for :P

Gosh, I'm not really sure about that. I don't have that much experience with setting up a repository, so take my answer with a grain of salt. If you're not going to create separate builds for each distro, adding separate targets to your repo will at most save some users from installing patches that don't apply to them, and you should ask yourself if that's worth the effort and maintenance on your side. If you do create separate builds and use separate targets, I suppose your advantage would be that you are less likely to have dependency conflicts, since you can have different dependency versions for different distros. (But I'm even more foreign to dependency management than I am to repository management.) Either way, this option, too, is more complex for you to manage. In the case of Signal, from what I've read, their use of `xenial` basically amounts to having only a `stable` build, but they don't want to rename it because that would require users to change their lists, which is too much effort for what it's worth. Looking at 3rd-party repos I'm using, there seems to be a direct correlation between the amount of money behind the project and the amount of distros they build for :P

jwijenbergh commented 2023年02月23日 15:44:05 +01:00 (Migrated from github.com)

Thanks! Then it's exactly what I figured the advantages and disadvantages are. Providing separate builds is not a big hassle right now as our builder allows for this easily. Just takes longer to build really.

In the case of Signal, from what I've read, their use of xenial basically amounts to having only a stable build, but they don't want to rename it because that would require users to change their lists, which is too much effort for what it's worth.

Ah! Makes sense I guess 😅

Thanks! Then it's exactly what I figured the advantages and disadvantages are. Providing separate builds is not a big hassle right now as our builder allows for this easily. Just takes longer to build really. > In the case of Signal, from what I've read, their use of xenial basically amounts to having only a stable build, but they don't want to rename it because that would require users to change their lists, which is too much effort for what it's worth. Ah! Makes sense I guess :sweat_smile:

jwijenbergh commented 2023年05月09日 17:54:56 +02:00 (Migrated from github.com)

Will re-open this when this becomes a viable option

Will re-open this when this becomes a viable option

Lukas-UAUX commented 2025年05月24日 01:15:00 +02:00

Ubuntu uses Deb822 as default since 24.04... so would this now be a viable option? ;-)

Ubuntu uses Deb822 as default since 24.04... so would this now be a viable option? ;-)