Upcoming APT cryptography changes for 24.04.1

[Julian Andres Klode]

On Tue, Jul 30, 2024 at 01:23:34PM GMT, Robie Basak wrote:
> To clarify my opinion, I should add that for LTS purposes, I think it's
> important that we have a path to "ratchet up" the minimum ciphersuite
> standard, and therefore it's appropriate to do in SRU as a policy.
> Theoretically this would be for any release, including past releases,
> and future ratchets that we might decide are appropriate after later
> releases have been around a while.
> 
> But we do want to avoid user suprise and where possible do it with
> plenty of notice, so it would be preferable for the actual mechanism to
> support this as well as is possible.
> 
> On Tue, Jul 30, 2024 at 05:27:20PM +0900, Julian Andres Klode wrote:
> > One option could be:
> > 
> > +        {
> > +            "begin": "2024-08-05T00:00:00Z",
> > +            "lines": [
> > +                "All PPAs are now dual signed with 4096-bit RSA keys.",
> > +                "Remove and readd PPAs to migrate to the new keys.",
> > +                "For more details see: https://ubuntu.com/blog/ubuntu-ppa-resigning"
> > +            ]
> >          }
> 
> What I intended in my suggestion was the following. Some of this you
> were already doing, but for completeness of my logic I'm listing all of
> the bits that I think are important:
> 
> 1. Make the change a configuration item that can be dropped into a .d/
> directory.

The default configuration is in apt-pkg/init.cc; we drop an override
in the maintainer script to downgrade it to a warning on upgrades from
earlier apt in noble.

This means that after rolling out the update:

1. Existing noble installs continue trusting rsa1024
2. Upgrades from mantic/jammy done after that point will no longer trust it
3. Installs form 24.04.2 media will not trust it

Importantly, this means LTS -> LTS upgrades should not ever get into an
in-between warning state which was the goal.

> 
> 2. The configuration should include a date from which it will happen, so
> that apt does it dynamically without any further configuration on the
> flag day.

I've talked to more people about making this a time bomb, but there's
concerns that this breaks stuff like test suites in the release pocket;
so there's an inclination to actually enable new flags with package
upgrades such that the change itself gets testing, and e.g. Azure
with its snapshot based rollout can do its normal testing rather than
having to special case it.

We don't yet have a date mechanism. The mechanism implemented provides
three levels, an unlabeled active one, a next one causing warnings, and
a 'future' level allowing messages in --audit messages (--audit is not
yet available in the noble SRU either). Each of which specify the list
of allowed algorithms in that level, in the format given to us by
GnuPG (or rather a strict subset).

This is the natural and minimal extension of the existing mechanism;
it's not necessarily the best mechanism yet. The mechanism was rejected
as inadequate by the Rust-Sequioa maintainers; hence their gpgv
reimplementation doesn't support it (installing gpgv-from-sq hence
disables the feature).

A new mechanism is in the works that instead of relying on the GnuPG
public key assertions on the signatures, parses the keyring itself
hence it knows *all* your configured keys (it also gives you the apt-key
list replacement people were asking for) [I read the pgpdump code and
roughly translated it to APT style].

That new mechanism is backportable. And we can choose to only issue
warnings, not errors, as they are now more effective. No longer is
there a case where you could have a repository with 2 keys configured,
no warnings because they now sign with a strong key and a MITM
downgrades you to a weak key.

But in any case, it seems advisable to improve the mechanism to specify
target dates for when we revoke trust, that said, this hasn't made it
in yet, this is something to look at for 24.04.2; trying to insert the
date algorithm last minute seems more regression potential.

> 
> 3. Prior to that date, apt would know it's coming and could then display
> a warning indicating that it is configured to change from that date.
> 
> And then there would be a path to making this enforced sooner for fresh
> installs for .1, but eventually converging with those who have installed
> .0, if that's what we choose to do.
> 
> The key thing is that then we can warn users in advance, and users would
> also be able to bump the date and/or manually override to avoid the
> "ratchet" entirely, without being surprised by interruption of service
> and frantic searching to mitigate an issue after it has affected them.
> 
> Ideally, if apt could expose the configuration file and line number that
> results in this bump, then a user would even be able to immediately see
> and bump the date without even having to look up the syntax.

Notably even now, they can copy the configuration file the update
creates to a different name; the problem is that they might forget
(though well, it still *warns* them) and never converge.

> 
> But I think in your example above the message relates to what would be
> displayed after it has happened, not before?

The mechanism above is for the apt-news mechanism shipped in the Pro
client, so we can ship that immediately once the PPAs are resigned, so
users know that happened.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20240731/57e8f4bd/attachment.sig>