Re: Bumping apt RSA key length requirements to 3072-bit (2048 w/ warning) for 24.04

2024-01-24 Thread Michael Hudson-Doyle
On Wed, 24 Jan 2024 at 20:48, Adrien Nader  wrote:

> On Wed, Jan 24, 2024, Michael Hudson-Doyle wrote:
> > On Tue, 23 Jan 2024 at 02:31, Jeremy Bícha 
> > wrote:
> >
> > > On Mon, Jan 22, 2024 at 7:36 AM Dimitri John Ledkov
> > >  wrote:
> > > > > Sadly shipping this in 24.04 means that PPAs owned by user
> > > > > accounts created prior to 2014-03-11[3] until the key rotation
> > > > > mechanism(s) [4][5] have been implemented.
> > > > >
> > > >
> > > > I do wonder how many active old PPA owners remain in action.
> > > >
> > > > And if we can reset per-series signing keys on all of those for any
> > > > new PPAs, and noble series (meaning single signe, new key for
> noble+).
> > > >
> > > > I have personally created a new team for myself, only added myself to
> > > > be a member of said team, to gain access to PPAs signed with 4k RSA
> > > > key, as I can no longer use my own ppas. I guess I should ask to
> > > > delete them all, and request removal of the signing key to gain back
> > > > personal PPAs with 4k signing key.
> > >
> > > Many of Ubuntu's core teams are older than 2014. This includes
> > > Desktop, Checkbox, Kernel, Pythoneers, Security, Mozilla, LibreOffice,
> > > Kubuntu, Lubuntu.
> > >
> > > I suspect that this change would break most of the heaviest used PPAs.
> > > We need a coordinated transition.
> > >
> >
> > I agree with Jeremy that we can't just blithely assume all PPAs created
> > before 2014 are no longer much used.
> >
> > Unfortunately I don't know what that means for a way forward. Clearly
> 1024R
> > keys should be retired. From one angle, I can imagine a scheme were a
> repo
> > is dual-signed and signs the new key with the old to convince apt to
> update
> > it but from another this seems impossible (and clearly very unlikely to
> > land before noble GA).
>
> We know of at least one active PPA with a 1024-bit key:
> https://launchpad.net/~videolan/+archive/ubuntu/master-daily .
>

I kind of misspoke in a way -- it's not the PPA that has to be old, as all
PPAs from a given owner are signed with the same key. It sounds slightly
more tractable to have Launchpad generate new keys for each owner and sign
new PPAs with that key. But a) not in time for noble b) this doesn't really
solve the problem anyway.

Cheers,
mwh
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: gedit: problematic 'gnome-text-editor' alternative

2024-01-24 Thread Amin Bandali
Robie Basak writes:

> On Thu, Jan 18, 2024 at 07:02:19AM -0500, Amin Bandali wrote:
>> We received https://bugs.debian.org/1057184 last month about gedit's
>> 'gnome-text-editor' alternative becoming problematic now that there is
>> an actual gnome-text-editor package/binary.
>
> It sounds like this is being looked at backwards. If the
> /usr/bin/gnome-text-editor name was already being used by packages using the
> alternatives system, then a gnome-text-editor package arrived that
> stepped on the name, then it's the latter package's bug that it collides
> without at a minimum declaring a Conflicts against those existing
> packages. It probably shouldn't just step on that name without
> coordinating with the maintainers of those packages.
>
> It's probably just an oversight, but I think it's important to consider
> it from this perspective. A package doesn't just get to take over a slot
> in the namespace that is already used for some purpose because an
> upstream decided to start using it.
>
> Therefore the bug should probably be reassigned to gnome-text-editor as
> it introduced a serious policy violation (section 10.1 "Two different
> packages must not install programs with different functionality but with
> the same filenames").

Thanks for your reply, Robie, and for offering that perspective.

To clarify, both gedit and gnome-text-editor are maintained by the
same people - the Debian GNOME team - and we are in agreement about
the severity of this.  It's just that the obscure alternative was
totally forgotten about - I believe it dates back at least 20 years,
way before gnome-text-editor was a project of its own.

We think the best way forward would be to remove the conflicting
alternative from gedit, rather than change gnome-text-editor to ship
its binary with a different name (or to declare it conflicting with
gedit, which would not be a desirable outcome and not conforming with
the policy anyway).

My main hope with this thread was to get feedback about the specific
approach for removing the alternative.  I think simply checking that
the alternative exists in postinst configure and removing it would be
enough.  I also made its removal in prerm more clearly conditional.

https://salsa.debian.org/gnome-team/gedit/-/merge_requests/11

Having tested a few different scenarios locally, I believe it works
well.  So, I've proposed it for review, and plan to upload to unstable
in the coming days if there's no further feedback or objections.

Thanks,
-a


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Bumping apt RSA key length requirements to 3072-bit (2048 w/ warning) for 24.04

2024-01-24 Thread Jeremy Bícha
On Wed, Jan 24, 2024 at 2:48 AM Adrien Nader  wrote:
>
> On Wed, Jan 24, 2024, Michael Hudson-Doyle wrote:
> > On Tue, 23 Jan 2024 at 02:31, Jeremy Bícha 
> > wrote:
> >
> > > On Mon, Jan 22, 2024 at 7:36 AM Dimitri John Ledkov
> > >  wrote:
> > > > > Sadly shipping this in 24.04 means that PPAs owned by user
> > > > > accounts created prior to 2014-03-11[3] until the key rotation
> > > > > mechanism(s) [4][5] have been implemented.
> > > > >
> > > >
> > > > I do wonder how many active old PPA owners remain in action.
> > > >
> > > > And if we can reset per-series signing keys on all of those for any
> > > > new PPAs, and noble series (meaning single signe, new key for noble+).
> > > >
> > > > I have personally created a new team for myself, only added myself to
> > > > be a member of said team, to gain access to PPAs signed with 4k RSA
> > > > key, as I can no longer use my own ppas. I guess I should ask to
> > > > delete them all, and request removal of the signing key to gain back
> > > > personal PPAs with 4k signing key.
> > >
> > > Many of Ubuntu's core teams are older than 2014. This includes
> > > Desktop, Checkbox, Kernel, Pythoneers, Security, Mozilla, LibreOffice,
> > > Kubuntu, Lubuntu.
> > >
> > > I suspect that this change would break most of the heaviest used PPAs.
> > > We need a coordinated transition.
> > >
> >
> > I agree with Jeremy that we can't just blithely assume all PPAs created
> > before 2014 are no longer much used.
> >
> > Unfortunately I don't know what that means for a way forward. Clearly 1024R
> > keys should be retired. From one angle, I can imagine a scheme were a repo
> > is dual-signed and signs the new key with the old to convince apt to update
> > it but from another this seems impossible (and clearly very unlikely to
> > land before noble GA).
>
> We know of at least one active PPA with a 1024-bit key:
> https://launchpad.net/~videolan/+archive/ubuntu/master-daily .

There are many more active 1024-bit PPAs. In my earlier reply. I
listed several teams that have 1024 bit keys. Some of those teams use
their PPAs for mostly development series work like Pythoneers and this
change may not be disruptive. For others, the PPA is an important
component of what they offer the community: like Kubuntu and Lubuntu.

Thank you,
Jeremy Bícha

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Bumping apt RSA key length requirements to 3072-bit (2048 w/ warning) for 24.04

2024-01-24 Thread Adrien Nader
On Wed, Jan 24, 2024, Michael Hudson-Doyle wrote:
> On Tue, 23 Jan 2024 at 02:31, Jeremy Bícha 
> wrote:
> 
> > On Mon, Jan 22, 2024 at 7:36 AM Dimitri John Ledkov
> >  wrote:
> > > > Sadly shipping this in 24.04 means that PPAs owned by user
> > > > accounts created prior to 2014-03-11[3] until the key rotation
> > > > mechanism(s) [4][5] have been implemented.
> > > >
> > >
> > > I do wonder how many active old PPA owners remain in action.
> > >
> > > And if we can reset per-series signing keys on all of those for any
> > > new PPAs, and noble series (meaning single signe, new key for noble+).
> > >
> > > I have personally created a new team for myself, only added myself to
> > > be a member of said team, to gain access to PPAs signed with 4k RSA
> > > key, as I can no longer use my own ppas. I guess I should ask to
> > > delete them all, and request removal of the signing key to gain back
> > > personal PPAs with 4k signing key.
> >
> > Many of Ubuntu's core teams are older than 2014. This includes
> > Desktop, Checkbox, Kernel, Pythoneers, Security, Mozilla, LibreOffice,
> > Kubuntu, Lubuntu.
> >
> > I suspect that this change would break most of the heaviest used PPAs.
> > We need a coordinated transition.
> >
> 
> I agree with Jeremy that we can't just blithely assume all PPAs created
> before 2014 are no longer much used.
> 
> Unfortunately I don't know what that means for a way forward. Clearly 1024R
> keys should be retired. From one angle, I can imagine a scheme were a repo
> is dual-signed and signs the new key with the old to convince apt to update
> it but from another this seems impossible (and clearly very unlikely to
> land before noble GA).

We know of at least one active PPA with a 1024-bit key:
https://launchpad.net/~videolan/+archive/ubuntu/master-daily .

On the other hand, we can probably imagine there are only a few of them.
How do we do a large-scale analysis however? Actually, I think I spotted
something in launchpadlib but I haven't used that library yet and would
have to spend time discovering it.

-- 
Adrien

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel