Re: git server changes - how to allow https AND ssh now that /srv/git/xxx.git must be owned by http?

[Ryan Petris]

On Sun, Jun 16, 2024, at 4:39 PM, David C. Rankin wrote:
> On 6/16/24 05:30, Guus Snijders wrote:
> > Have you tried using http:david instead?
> > And make sure the files are group-writable.
> > 
> > I haven't tested this, but this seems to answer all the mentioned 
> > constraints.
> > 
> 
> Thank you Guus,
> 
>Unfortunately, yes, I've tried every combination of user:group ownership 
> and it is really unfortunate that git won't server https unless the 
> directories are 'owned' by http. I've even tried adding myself to the http 
> group, but no luck.
> 
>Why I can't chmod 0775 repodir.git and then use david:http is indeed 
> stange, but git requires http:dontcare to server https.
> 
>Of course ssh requires david:dontcare to server git over ssh.
> 
>I'll have to try Ryan's binfs work around and see if I can make something 
> like that work. It's just wild that git doesn't have a published fix for this 
> after the security change.
> 
>github does something. I can pull over https and ssh still works there. It 
> may be worth opening an issue with git to see how they feel this catch 22 
> should be handled for locally hosted servers. If I find a fix, I'll report 
> back.
> 
> -- 
> David C. Rankin, J.D.,P.E.
> 

You mentioned:

> github does something. I can pull over https and ssh still works there.

I *highly* doubt GitHub uses standard Git in their backend at all. Your git 
repository is probably sitting in chunks somewhere in a highly distributed 
database with lots of indexing and whatnot added on top; you're not just 
connecting to a server and pulling the repo directly off disk somewhere. It may 
have started off using standard git, but I'll eat my hat if it still is.

I had the "pleasure" of using/administering TFS (Microsoft Team Foundation 
Server) 8+ years ago when they introduced Git support; I spent a while trying 
to figure out where they stored the git repositories until I found that 
everything was in the database, just like everything else in TFS. They just 
implemented a git-compatible API of sorts where Git thinks it's talking to a 
regular git server.

Re: git server changes - how to allow https AND ssh now that /srv/git/xxx.git must be owned by http?

[Ryan Petris]

On Sun, Jun 16, 2024, at 3:30 AM, Guus Snijders wrote:
> Op zo 16 jun. 2024 10:42 schreef David C. Rankin :
>> [···]
>>On the server the repositories under /srv/git were owned david:david 
>> (me). 
>> However, after the git change, git refused to serve over https unless the 
>> directories under /srv/git were owned by http.
>> 
>>Fine, change made - but now repos cloned read/write over ssh fail because 
>> the directory under /srv/git is no longer owned by me.
>> 
>>How do you make git repositories hosted on my local server allow 
>> clone/pull 
>> over https AND allow me to still close read/write over ssh?
>> [...]
>> unless /srv/git/xxx.git is http:http, https fails
>> 
>> unless /srv/git/xxx.git is david:http, ssh fails
> 
> 
> Have you tried using http:david instead?
> And make sure the files are group-writable.
> 
> I haven't tested this, but this seems to answer all the mentioned constraints.
> 
> 
> Mvg, Guus Snijders

You could try using something like bindfs (https://bindfs.org/) to bind mount 
/srv/git somewhere else with different permissions. Based on the man page it 
looks like you could do something like `bindfs --map http/git --map-group 
http/git /srv/git /srv/git-http`, then point apache to /srv/git-http instead of 
/srv/git.

Re: Arch Linux Rust packaging licensing problem

[Ryan Petris]

On Sun, Apr 7, 2024, at 12:42 PM, tippfehlr wrote:
> Hi,
> 
> > Replying on the general mailing list since the dev list is staff only.
> 
> tried to reply to arch-dev-public earlier, that explains why it didn’t work.
> 
> > Personally I think having incomplete SPDX identifier in the pacman 
> > package is not in itself a license violation as long as the individual 
> > license files are shipped with the package. Although it would certainly 
> > be nice for tooling if the package information is complete too.
> 
> I think having the licenses of all dependencies in the license field is
> (1) a lot of clutter and (2) not what I would expect.
> 
> If I want to check under which license linux is released, the result
> 
> $ pacman -Si linux
> ...
> Licenses: GPL-2.0-only
> ...
> 
> is a lot more useful (to me) than
> 
> $ pacman -Si linux-lts
> ...
> Licenses: Apache-2.0 OR MIT  BSD-2-Clause OR GPL-2.0-or-later
>   BSD-3-Clause  BSD-3-Clause OR GPL-2.0-only
>   BSD-3-Clause OR GPL-2.0-or-later  BSD-3-Clause-Clear
>   GPL-1.0-or-later  GPL-1.0-or-later OR BSD-3-Clause
>   GPL-2.0-only  GPL-2.0-only OR Apache-2.0
>   GPL-2.0-only OR BSD-2-Clause  GPL-2.0-only OR BSD-3-Clause
>   GPL-2.0-only OR CDDL-1.0  GPL-2.0-only OR Linux-OpenIB
>   GPL-2.0-only OR MIT  GPL-2.0-only OR MPL-1.1
>   GPL-2.0-only OR X11  GPL-2.0-only WITH Linux-syscall-note
>   GPL-2.0-or-later  GPL-2.0-or-later OR BSD-2-Clause
>   GPL-2.0-or-later OR BSD-3-Clause  GPL-2.0-or-later OR MIT
>   GPL-2.0-or-later OR X11
>   GPL-2.0-or-later WITH GCC-exception-2.0  ISC
>   LGPL-2.0-or-later  LGPL-2.1-only
>   LGPL-2.1-only OR BSD-2-Clause  LGPL-2.1-or-later  MIT
>   MPL-1.1  X11  Zlib
> ...
> 
> (though I’m not sure why they differ)
> 
> Best regards,
> tippfehlr
> 
> 
> *Attachments:*
>  • signature.asc

I agree with this.

The "license" of the package isn't the collection of licenses that make up the 
software along with all of its libraries, it's the license of the software 
itself. Including the license of all the libraries in the "license" field would 
just muddy the waters and make that field effectively useless.

What could be done, IMO, is that all of the relevant licenses and copyright 
notices be included in the licenses directory for that package, for instance:

/usr/share/licenses//LICENSE_

Based on my knowledge and readings of open source licenses (I am not a lawyer 
and this is not legal advice), this should satisfy the majority if not all 
conditions of binary distribution of licenses.

However, I do think that the rust/cargo maintainers need to have some skin in 
the game here (along with go, nodejs, and similar languages) and have some way 
of dumping the licenses of dependencies. When you have a packaging system that 
makes it easy to pull in hundreds of dependencies, there should be an easy way 
of checking what those licenses are anyway because you could otherwise end up 
in a bad situation.

Re: `makepkg` generates two packages

[Ryan Petris]

On Thu, Mar 7, 2024, at 6:45 AM, Martin Rys wrote:
> If you had the configuration autoreplaced it would mean you never edited it - 
> in which case you'd be building packages on a single thread... Surely not?
> 
> Martin 
> 
> On Thu, Mar 7, 2024, 14:41 Ryan Petris  wrote:
>> __
>> On Thu, Mar 7, 2024, at 4:38 AM, Robin Candau wrote:
>>> On 3/7/24 12:34, lacsaP Patatetom wrote:
>>> > hi,
>>> Hi,
>>> > 
>>> > when I run `makepkg`, it generates a second package with the `-debug` 
>>> > "extension" (eg. `mypackage-w.x.y-z-x86_64.pkg.tar.zst` and 
>>> > `mypackage-debug-w.x.y-z-x86_64.pkg.tar.zst`).
>>> > 
>>> > I couldn't find anything about this on the wiki : is this a new feature 
>>> > and/or is there a parameter to pass to `makepkg` to avoid building it ?
>>> > 
>>> Debug packages have been introduced in Arch in early 2022.
>>> See https://archlinux.org/news/debug-packages-and-debuginfod/
>>> > regards, lacsaP.
>>> 
>>> -- 
>>> Regards,
>>> Robin Candau / Antiz
>>> 
>>> 
>>> 
>>> *Attachments:*
>>>  • OpenPGP_0xFDC3040B92ACA748.asc
>>>  • OpenPGP_signature.asc
>> 
>> Arch itself may have been generating debug packages since 2022, however it's 
>> only recently that makepkg started spitting out debug packages by default. 
>> The change was made all the way back in June of last year 
>> <https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/commit/90bf367e61b4f77f8351d0412be3d0c4ddadb85a>,
>>  but was only included in a pacman release at the beginning of February 
>> <https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/tags/6.0.2-9>,
>>  as part of a pkgrel bump.
>> 
>> This came as a surprise to me as well, when I had -debug packages start 
>> showing up in my personal repository when they had not before, without any 
>> changes made on my end.
>> 
>> Personally I would have expected some sort of announcement for this change, 
>> though there was none.

Prior to needing to modify options, my changes to makepkg consisted of:

echo 'MAKEFLAGS="-j$(nproc)"' >> /etc/makepkg.conf

So yes, it's possible.

On that note, I'm building my packages using standard github actions; I don't 
believe those are multi-threaded anyway.

Re: `makepkg` generates two packages

[Ryan Petris]

On Thu, Mar 7, 2024, at 4:38 AM, Robin Candau wrote:
> On 3/7/24 12:34, lacsaP Patatetom wrote:
> > hi,
> Hi,
> > 
> > when I run `makepkg`, it generates a second package with the `-debug` 
> > "extension" (eg. `mypackage-w.x.y-z-x86_64.pkg.tar.zst` and 
> > `mypackage-debug-w.x.y-z-x86_64.pkg.tar.zst`).
> > 
> > I couldn't find anything about this on the wiki : is this a new feature 
> > and/or is there a parameter to pass to `makepkg` to avoid building it ?
> > 
> Debug packages have been introduced in Arch in early 2022.
> See https://archlinux.org/news/debug-packages-and-debuginfod/
> > regards, lacsaP.
> 
> -- 
> Regards,
> Robin Candau / Antiz
> 
> 
> 
> *Attachments:*
>  • OpenPGP_0xFDC3040B92ACA748.asc
>  • OpenPGP_signature.asc

Arch itself may have been generating debug packages since 2022, however it's 
only recently that makepkg started spitting out debug packages by default. The 
change was made all the way back in June of last year 
,
 but was only included in a pacman release at the beginning of February 
,
 as part of a pkgrel bump.

This came as a surprise to me as well, when I had -debug packages start showing 
up in my personal repository when they had not before, without any changes made 
on my end.

Personally I would have expected some sort of announcement for this change, 
though there was none.