[FFmpeg-devel] git problems

[Michael Niedermayer]

On Thu, May 30, 2024 at 10:27:31AM +0100, Andrew Sayers wrote:
> On Thu, May 30, 2024 at 01:30:09AM +0200, Michael Niedermayer wrote:
> > Hi all
> > 
> > It seems the security update (https://ubuntu.com/security/notices/USN-6793-1)
> > broke public git
> > 
> > We use gitolite that runs under its own user and serve git through apache
> > which runs under a different user.
> > Apache has only read access to the repositories
> > 
> > Since the security update that stoped working, the logs are full of messages
> > telling that we need to add the repositories to safe.directory
> > (the commands suggested dont work and seem to mix up \t with a tab but thats besides the point)
> > once the repository is added to safe.directory, which ive done with https://git.ffmpeg.org/michael.git
> > the error is gone and everything looks fine in the logs on the server but it still
> > doesnt work. (i have not touched ffmpeg.git config as i first wanted to test this)
> > 
> > So like i just said on IRC. i hope some of the other root admins will have
> > some more insight here. Or if you (yes YOU!) want to help or know something
> > please speak up.
> > 
> > This is totally not my area and i think other people could find the issue
> > with less effort in less time and it would be more efficient if i work
> > on FFmpeg instead where the return per hour of my time should be much greater.
> > 
> > Also gitweb and git over ssh seem uneffected and theres github
> > 
> > If people want i could downgrade git OR
> > upgrade git to latest git ignoring official ubuntu packages
> > otherwise, i intend to leave this for someone else to investigate and rather
> > work on FFmpeg which just seems like a much better use of my time
> 
> You've talked recently about looking for STF money to upgrade the servers.

> You might want to write up a postmortem when the bug is fixed,

i will suggest this to raz once we understand teh issue fully


[...]

> One thing for the postmortem - I don't know enough about these specific
> programs to do much with the description provided.  And even if I did, I could
> only offer prose hints at a solution.  But containerising these services would
> let me replicate the server locally, and suggest solutions as normal patches
> on the mailing list.

the box is a VM currently so one could in principle clone it.
only that various private keys (for example for SSL certs) and
personal data (like IP addresses in log files) would be in it
making public sharing impossible
also there are likely other reasons why publically sharing such a clone
would be a bad idea.

i dont see how containerising would change this.
IMHO the effort to make sure a container would be safe security and privacy
wise to share publically outweights the benefit.

If someone wants to reproduce this locally, setup a ubuntu focal, setup gitolite
setup apache and try to do a git clone via https. with latest git vs the
version from 3 days ago, that should probably replicate it.
If one person builds such a test setup, (s)he can share this with everyone
I think the effort here is quite a bit lower than trying to make the live
servers publically sharable. (and it costs us 0 time and 0 $)
anyway not suggesting anyone does this. Just saying, IF someone really
wants to replicate it.

raz has found a workaround already with the current git version, but we
still have incomplete understanding of teh issue

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240530/168ab8e0/attachment.sig>