leap-archive-keyring should not install a globally valid trust anchor

We have a version of this keyring package that solves this problem, that we have been testing for some time, it has not been uploaded to debian because we've been working out the repository overhaul, but I think it probably could be uploaded soon.

If you want to test it, you can use this sources.list:

deb [signed-by=CE433F407BAB443AFEA196C1837C1AD5367429D9] http://deb.leap.se/client staging stretch

which problem specifically?

the location of the trust anchor or the preferences file? or both? :)

i'd be curious to hear what you think, as an upstream, of the proposal for how to distribute third-party debian packages...

thanks!

I wasn't specifically saying anything about any specific problem, just pointing out that we've actually fixed the trust anchor already, it just isn't uploaded and if you wanted to test it, that is how.

Regarding preferences modifications - i'm not sure what you mean by a pinnned preferences file in the archive. I am not aware of such a thing available in an archive, only on client machines. We are not going to ask users to add preferences file entries to their configs.

I wasn't specifically saying anything about any specific problem, just pointing out that we've actually fixed the trust anchor already, it just isn't uploaded and if you wanted to test it, that is how.

I'm a little confused here. Is the leap-archive-keyring package available from the staging repository? Or is there something else fixed in that repository that I should test?

anarcat gitlab@0xacab.org writes:

I wasn't specifically saying anything about any specific problem, just pointing out that we've actually fixed the trust anchor already, it just isn't uploaded and if you wanted to test it, that is how.

I'm a little confused here. Is the leap-archive-keyring package available from the staging repository? Or is there something else fixed in that repository that I should test?

Yes, the package is available from the staging repository, as I said in #6 (comment 127303)

The package was uploaded to debian

closed

The version in the Debian archive now still has this problem in that it installs a global trust anchor in /etc:

root@angela:/etc/apt/sources.list.d# dpkg -l leap-archive-keyring | cat
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                  Version           Architecture Description
+++-====================-=================-============-=========================================================
ii  leap-archive-keyring 2017.11.24~bpo9+1 all          OpenPGP archive key for the leap.se software repositories
root@angela:/etc/apt/sources.list.d# dpkg -L leap-archive-keyring | grep trusted.gpg.d/
/etc/apt/trusted.gpg.d/leap-archive.gpg
/etc/apt/trusted.gpg.d/leap-experimental-archive.gpg

Furthermore, the install instructions do not follow the best practices of anchoring the sources.list line into the trust anchor. This line:

sudo sh -c 'echo "deb http://deb.leap.se/client release stretch" > /etc/apt/sources.list.d/bitmask.list'

Should really be:

sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/leap-archive.gpg] http://deb.leap.se/client release stretch" > /etc/apt/sources.list.d/bitmask.list'

... as well. I would be happy to send merge requests to fix this if this is not a policy decision.

I have also reopened the bug report on Debian's side.

reopened

anarcat gitlab@0xacab.org writes:

The version in the Debian archive now still has this problem in that it installs a global trust anchor in /etc:

root@angela:/etc/apt/sources.list.d# dpkg -l leap-archive-keyring | cat
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                  Version           Architecture Description
+++-====================-=================-============-=========================================================
ii  leap-archive-keyring 2017.11.24~bpo9+1 all          OpenPGP archive key for the leap.se software repositories
root@angela:/etc/apt/sources.list.d# dpkg -L leap-archive-keyring | grep trusted.gpg.d/
/etc/apt/trusted.gpg.d/leap-archive.gpg
/etc/apt/trusted.gpg.d/leap-experimental-archive.gpg

Yes, these are deliberately there because we need to have them in both locations in order to support transition to new sources.list entries.

In package 2017.05.01 I moved the keyrings from /etc/apt/trusted.gnupg.d to /usr/share/keyrings, but then this caused significant pain because many people had not updated their sources.list and now the keyring is no longer trusted. Combine that with the support for Jessie, which does not support this, made this a complete mess. So to aid the transition, the keys are in 2017.11.24 provided in trusted.d as well as /usr/share/keyrings.

I'm unsure which ubuntu version supports the non-global trust anchor sources.list entries, but we decided that while this is a nice advancement, the pain of being a first-mover here was not worth doing this until things had settled more.

Perhaps things have settled more, but to do this means we need to somehow convince existing users to change their sources.list before we remove the key from trusted.d, not very user friendly here. There is no clean way to do this transition, the only way this will happen is a making a lot of noise in blog posts, twitter, mailing lists, irc, etc. telling people to change (the success rate would be expected to be low); and then at some point "just doing it", causing everyone who didn't hear about this to have their apt update to fail. The user experience here is awful. The results of this will be either people finding our posts about this (yay), coming to us to ask what is going on (meh), giving up on us and removing it to make the error go away (ugh), or ignoring it (also ugh). We do not expect the 'yay' scenario to have a significant percentage of this.

Regardless, none of these are smooth, nor desirable outcomes.

I'd like to see this happen, and be adopted generally, but so far us going ahead with this, when practically nobody else in the universe does this, has been very ugly and caused us a lot of problems with users.

Perhaps apt could be improved to make this transition smoother. I'm not sure how, but maybe suggesting people make these changes so you can transition to this new setup without a flag day?

Furthermore, the install instructions do not follow the best practices of anchoring the sources.list line into the trust anchor. This line:
sudo sh -c 'echo "deb http://deb.leap.se/client release stretch" > /etc/apt/sources.list.d/bitmask.list'
Should really be:
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/leap-archive.gpg] http://deb.leap.se/client release stretch" > /etc/apt/sources.list.d/bitmask.list'
... as well. I would be happy to send merge requests to fix this if this is not a policy decision.

We discussed this, but decided against it for now.

There is a strong desire in LEAP to make the installation instructions as minimal, clear and non-arcane as possible. Even the existing documentation causes significant apoplectic pain to some and the resistance against a curl | sudo bash installation process has been hard to sustain.

Yes, these are deliberately there because we need to have them in both locations in order to support transition to new sources.list entries.

In package 2017.05.01 I moved the keyrings from /etc/apt/trusted.gnupg.d to /usr/share/keyrings, but then this caused significant pain because many people had not updated their sources.list and now the keyring is no longer trusted. Combine that with the support for Jessie, which does not support this, made this a complete mess. So to aid the transition, the keys are in 2017.11.24 provided in trusted.d as well as /usr/share/keyrings.

I understand the desire to provide a smooth transition. Maybe that problem can be solved with a NEWS.Debian entry to tell people to update their sources.list?

Alternatively, what I did in the past was to install a sources.list entry directly from the package. It's a config file so changes will be respected, but it allows us to provide that transition for users.

As for jessie users, the reason this is a problem is because the backport is available in the first place: that backport could have a symlink in /etc - it doesn't have to be present in stretch or sid.

I'm unsure which ubuntu version supports the non-global trust anchor sources.list entries, but we decided that while this is a nice advancement, the pain of being a first-mover here was not worth doing this until things had settled more.

I'm not sure either: jessie has APT 1.0 and stretch has 1.4, so presumably that feature was introduced somewhere in between. Ubuntu trusty (LTS until 2019-04) has 1.0, Xenial (LTS until 2012-04) has 1.2 and bionic (current LTS) has 1.6.

According to the APT changelog, the Signed-By option was introduced in 1.1~exp9, so jessie is indeed SOL but most Ubuntu LTS releases are okay.

[...]

Perhaps apt could be improved to make this transition smoother. I'm not sure how, but maybe suggesting people make these changes so you can transition to this new setup without a flag day?

IMHO, the proper way to do this is to deploy the sources.list entry yourselves.

Furthermore, the install instructions do not follow the best practices of anchoring the sources.list line into the trust anchor. This line:
sudo sh -c 'echo "deb http://deb.leap.se/client release stretch" > /etc/apt/sources.list.d/bitmask.list'
Should really be:
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/leap-archive.gpg] http://deb.leap.se/client release stretch" > /etc/apt/sources.list.d/bitmask.list'
... as well. I would be happy to send merge requests to fix this if this is not a policy decision.
We discussed this, but decided against it for now.

There is a strong desire in LEAP to make the installation instructions as minimal, clear and non-arcane as possible. Even the existing documentation causes significant apoplectic pain to some and the resistance against a curl | sudo bash installation process has been hard to sustain.

This could also be solved by the keyring package installing the sources.list directly.

A.

I understand the desire to provide a smooth transition. Maybe that problem can be solved with a NEWS.Debian entry to tell people to update their sources.list?

I dont think a NEWS entry telling people to cast an arcane spell is particularly user-friendly, and doesn't resolve the issue with the instructions being even more crazy.

Alternatively, what I did in the past was to install a sources.list entry directly from the package. It's a config file so changes will be respected, but it allows us to provide that transition for users.

Maybe... however there are a number of issues here:

existing users who have sources.list entries - how does this work, or does it? if you add an entry in sources.list.d that has the right entry, but they have an entry elsewhere that is not the right entry, what happens?
the leap platform is still jessie. upgrading to stretch is in progress, but the lack of support in jessie of this feature blocks this until the transition has happened.
is installing a sources.list entry to a 3rd-party repository in a package is ok from a debian stand-point? I do not know. I have zero information about this, except a vague memory of some package installing something like this without notifying people making people very mad (chromium?). Do you have any examples of packages in Debian where this is done, or discussion on debian-devel where people have agreed that this is acceptable within certain paramters?
if we did this, the 'leap-archive-keyring' package name would not be what you would think the package would do (provide the keyring). One solution to that would be making a second package (ugh) that would install the sources.list entry and depend on the keyring... Not sure that this is a desirable outcome to make, maintain, and ask Debian to carry two packages for this.

As for jessie users, the reason this is a problem is because the backport is available in the first place: that backport could have a symlink in /etc - it doesn't have to be present in stretch or sid.

This is not a problem with jessie, because the leap-archive-keyring package does not do the thing that breaks in jessie (in otherwords, it does basically what you are saying it could do).

I'm unsure which ubuntu version supports the non-global trust anchor sources.list entries, but we decided that while this is a nice advancement, the pain of being a first-mover here was not worth doing this until things had settled more.

I'm not sure either: jessie has APT 1.0 and stretch has 1.4, so presumably that feature was introduced somewhere in between. Ubuntu trusty (LTS until 2019-04) has 1.0, Xenial (LTS until 2012-04) has 1.2 and bionic (current LTS) has 1.6.

According to the APT changelog, the Signed-By option was introduced in 1.1~exp9, so jessie is indeed SOL but most Ubuntu LTS releases are okay.

Ok, thanks for that.

Nevertheless... Can you give any examples of any user-friendly project that has a lot of users adopting this? no, I don't mean a project that 5 power users are using :P

We've already been burned by trying to do this over a year ago, and while it can be fun to be a trail-blazer, this has not been fun. It strikes me as not particularly a good idea to pick this up and be a trail-blazer again, when a year later we'd still be the first one doing this still...? I would rather wait for other projects to adopt this, work out the corner cases, make the transition smooth by getting burned, and then we'd be happy to adopt it as well...

I understand the desire to provide a smooth transition. Maybe that problem can be solved with a NEWS.Debian entry to tell people to update their sources.list?

I dont think a NEWS entry telling people to cast an arcane spell is particularly user-friendly, and doesn't resolve the issue with the instructions being even more crazy.

Meh. It's either this or you hope people will magically figure out what to do some other way. :) At some point the bullet will need to be bitten...

Alternatively, what I did in the past was to install a sources.list entry directly from the package. It's a config file so changes will be respected, but it allows us to provide that transition for users.

Maybe... however there are a number of issues here:

existing users who have sources.list entries - how does this work, or does it? if you add an entry in sources.list.d that has the right entry, but they have an entry elsewhere that is not the right entry, what happens?

I don't actually know. It's the tricky bit, of course.

the leap platform is still jessie. upgrading to stretch is in progress, but the lack of support in jessie of this feature blocks this until the transition has happened.

I would argue this can be restricted to the jessie backport. It's fine if the jessie backport ships stuff in /etc, but the upstream stuff in stretch shouldn't.

is installing a sources.list entry to a 3rd-party repository in a package is ok from a debian stand-point? I do not know.

It's up for debate, at this point, clearly. There are zero established standards for this right now. For some mysterious reason, no one actually sat down and wrote a proposal for this until I did, and it does not seem to have gotten much traction just yet.

The other project I poked about this is grml.org and they were happy to factor in most of my suggestions, but this one is where they were the most hesitant. So far, they seem to be looking towards packaging sources.list in a separate package because they are also uncomfortable with shipping it in the keyring package:

https://github.com/grml/grml-debian-keyring/pull/3#issuecomment-393884565

I have zero information about this, except a vague memory of some package installing something like this without notifying people making people very mad (chromium?). Do you have any examples of packages in Debian where this is done, or discussion on debian-devel where people have agreed that this is acceptable within certain paramters?

Not really. I haven't made much noise about this just yet and somewhat expected others to magically pick it up. :p I got a little burnt out working on this, to be honest and the only thing I did with it, so far, is to try my luck with a few third party repositories to see how the instructions work out for them. Your feedback, in that regard, is then of course very useful. :)

And yes, chromium is one of the Debian packages that create such an entry in sources.list - but not only that: it also created a cronjob to automatically upgrade the package. For me that was the line that the package should not cross...

if we did this, the 'leap-archive-keyring' package name would not be what you would think the package would do (provide the keyring). One solution to that would be making a second package (ugh) that would install the sources.list entry and depend on the keyring... Not sure that this is a desirable outcome to make, maintain, and ask Debian to carry two packages for this.

I see two solutions for this:

yes, maintain a second package (but at this point it might be better to look at packaging LEAP in Debian directly :p)
change the name of the package (leap-archive-bootstrap?) to reflect it does more than packaging a keyring

#1 (closed) is what grml people proposed as well.

As for jessie users, the reason this is a problem is because the backport is available in the first place: that backport could have a symlink in /etc - it doesn't have to be present in stretch or sid.

This is not a problem with jessie, because the leap-archive-keyring package does not do the thing that breaks in jessie (in otherwords, it does basically what you are saying it could do).

Of course. What I'm saying is stretch and later shouldn't ship /etc.

[...]

Nevertheless... Can you give any examples of any user-friendly project that has a lot of users adopting this? no, I don't mean a project that 5 power users are using :P

No, I can't. I'm sorry to say you're one of my guinea pigs on this. :)

We've already been burned by trying to do this over a year ago, and while it can be fun to be a trail-blazer, this has not been fun. It strikes me as not particularly a good idea to pick this up and be a trail-blazer again, when a year later we'd still be the first one doing this still...? I would rather wait for other projects to adopt this, work out the corner cases, make the transition smooth by getting burned, and then we'd be happy to adopt it as well...

Sure, I see where you're coming from. I am coming at it more from a "documentation" and "end-goal" standpoint: the bug here is not "fixed" anymore and while I understand it may be difficult or impossible to fix it in the short term, I think it might certainly be possible to do so in the long term.

But then, in the long term, the end goal might be more to just ship those packages directly in Debian itself, which might be a better use of your time... :)

I hope that helps!

A.

leap-archive-keyring should not install a globally valid trust anchor

Designs

Child items ...

Activity