Hi Santiago, we are aware of the situation and following that thread you pasted. Thanks a bunch for let's know! []'s On Fri, 2024-05-31 at 12:34 -0300, Santiago Ruano Rincón wrote: > Hi Ubuntu security team, > > I would just like to put you in the loop about this git issue, and a > possible regression in Ubuntu related to its fix. Please, see below. > > El 31/05/24 a las 10:41, Roberto C. Sánchez escribió: > > Hi Sean, > > > > On Fri, May 31, 2024 at 03:05:35PM +0100, Sean Whitton wrote: > > > Hello, > > > > > > Upstream's patches for these CVEs involve making it a lot > > > fiddlier to > > > use shared repositories where write access is managed using Unix > > > permissions, rather than by using SSH identities. > > > And indeed someone has reported a case of this a few days ago: > > > < > > > https://lore.kernel.org/git/924426.1716570031@dash.ant.isi.edu/T/#u> > > > ;. > > > > > > > I actually was bitten by this exact issue yesterday after an update > > to a > > server running Ubuntu 22. > > > > The really annoying thing is that the work-around of setting > > safe.directory has to be done on the server side. In the case of a > > server which uses system users but which does not permit shell log > > in, > > it would not even be possible for an affected user to set the > > configuration, unless an administrator sets it per-user or system- > > wide. > > > > It took several hours of troubleshooting to figure this out, as all > > of > > the discussions that came up regarding the "dubious permissions" > > error > > related to a CVE from 2022 and simply said to set safe.directory > > (implying that it was a client-side setting). > > > > > I think that this regression would be significant enough in an > > > LTS > > > context -- it's an older way of doing git repository hosting -- > > > that we > > > should leave these two CVEs unpatched for now. > > > > > I concur that the hassle which will almost certainly ensue from > > patching > > these CVEs would outweigh any potential benefit. Especially since > > depending on the specifics of the environment into which an update > > containing these patches is deployed, it may actually bring a > > development team's work entirely to a halt. > > > > We have reverted patches for lesser impacts, so it seems prudent to > > not > > deploy them in the first place for these two CVEs. > > > > > I also note: the commit message for the fix for CVE-2024-32465 > > > says that > > > it renders the fix for CVE-2024-32004 "somewhat redundant". > > > My understanding of the situation is that the fix for CVE-2024- > > > 32465 > > > does fix the issue strictly designated by CVE-2024-32004, and > > > without > > > the sort of usability regression linked above. > > > > > > Could someone review this assessment, please? > > > > > I haven't assessed this, but I will and then I will reply to this > > thread > > again with my assessment. > > > > Regards, > > > > -Roberto > > > > -- > > Roberto C. Sánchez > > > > Cheers, > > -- Santiago
Attachment:
signature.asc
Description: This is a digitally signed message part