Re: Embedded buildpath via rpath using cmake

[Seth Arnold]

On Fri, Feb 04, 2022 at 10:49:43AM +, Simon McVittie wrote:
> CMake removes the RUNPATH
> just before installation, so it doesn't become a security problem,
> but that's too late to stop it from affecting the build-ID - and the
> *length* of the build directory can also affect the contents of the
> binary, because when RUNPATHs are removed, it is done by overwriting
> them with zeroes in-place, leaving a run of zeroes with the same length
> as the removed RUNPATH.

Aha! This was the piece I was missing. I hadn't figured out that cmake
was resetting the RUNPATHs along the way, which explains why I didn't
spot any /nonexistant/whatever/... strings in any of my checks.

Excellent explanation as usual.

Thanks


signature.asc
Description: PGP signature

Bug#1004991: ITP: glyphtools -- Routines for extracting information from font glyphs

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: glyphtools
  Version : 0.8.0
  Upstream Author : Simon.Cozens.
* URL : https://github.com/simoncozens/glyphtools
* License : Apache-2.0
  Programming Lang: Python
  Description : Routines for extracting information from font glyphs

 Package provides many routines to obtain information about font glyphs from
 font binaries or font project files.
 .
 Main features provide by the API:
 - Return the category of the given glyph.
 - Set the category of the glyph in the font.
 - Return glyph metrics as a dictionary.
 - Return the Arabic rise of the glyph (Y difference between entry and exit).
 - Return the Arabic run of the glyph (X difference between entry and exit).
 - Organise a dictionary into a number of bins.
 - Organise glyphs according to a given metric.
 - Return the glyph as a set of beziers.BezierPath objects.
 - Add a new glyph to the font duplicating an existing one.

Re: Legal advice regarding the NEW queue

[Philip Hands]

Scott Kitterman  writes:

> On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
>> Scott Kitterman  writes:
>> 
>> ...
>> 
>> > Currently the only answer is join the FTP Team as a trainee when there
>> > is a call for volunteers. I totally get the frustration.
>> 
>> People could always just send additional data points to the relevant ITP
>> bug, like this:
>> 
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10
>> 
>> If that's actually useful for FTP team members, it could be encouraged
>> on the New queue page.
>> 
>> A link to a wiki page with suggestions of what to check, and how best to
>> submit reports in order to make them most useful would probably do the
>> trick.
>> 
>> Would that actually help?
>
> I'm not sure what the best solution is as far as notification goes.  
> Generally 
> we don't look at the ITP when reviewing packages (ITP isn't even required, so 
> it's really outside our scope).

I only went for that because it is at least linked to from the New entry
(if there's an ITP).

> A comment to the ITP should get to the original packager. If it's a
> worthwhile issue they can fix and re-upload.
>
> Most packages are currently available on Salsa even though not directly 
> available through the New queue.  A copy of the New queue does exist on 
> coccia, but it's not currently readable for non-FTP Team members.  It's 
> probably not too hard to change that if it turns out having other DDs review 
> things is useful.
>
> Right to the ITP bug and mention it on #debian-ftp might not be a bad way to 
> start experimenting with external reviews.

OK, done that, so let's see if it's deemed useful.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
> Scott Kitterman  writes:
> 
> ...
> 
> > Currently the only answer is join the FTP Team as a trainee when there
> > is a call for volunteers. I totally get the frustration.
> 
> People could always just send additional data points to the relevant ITP
> bug, like this:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10
> 
> If that's actually useful for FTP team members, it could be encouraged
> on the New queue page.
> 
> A link to a wiki page with suggestions of what to check, and how best to
> submit reports in order to make them most useful would probably do the
> trick.
> 
> Would that actually help?

I'm not sure what the best solution is as far as notification goes.  Generally 
we don't look at the ITP when reviewing packages (ITP isn't even required, so 
it's really outside our scope).  A comment to the ITP should get to the 
original packager.  If it's a worthwhile issue they can fix and re-upload.

Most packages are currently available on Salsa even though not directly 
available through the New queue.  A copy of the New queue does exist on 
coccia, but it's not currently readable for non-FTP Team members.  It's 
probably not too hard to change that if it turns out having other DDs review 
things is useful.

Right to the ITP bug and mention it on #debian-ftp might not be a bad way to 
start experimenting with external reviews.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Legal advice regarding the NEW queue

[Philip Hands]

Scott Kitterman  writes:

...
> Currently the only answer is join the FTP Team as a trainee when there
> is a call for volunteers. I totally get the frustration.

People could always just send additional data points to the relevant ITP
bug, like this:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10

If that's actually useful for FTP team members, it could be encouraged
on the New queue page.

A link to a wiki page with suggestions of what to check, and how best to
submit reports in order to make them most useful would probably do the
trick.

Would that actually help?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Christian Kastner]

On 2022-02-04 18:39, Russ Allbery wrote:
> In other words, this thread is once again drifting into a discussion of
> how to do copyright review *better*, when my original point is that we
> should seriously consider not doing the current type of incredibly tedious
> and nit-picky copyright review *at all*, and instead rely more on
> upstream's assertions, automated tools, and being reactive in solving the
> bugs that people actually care about (i.e., notice).

If we're honest, that's basically how the rest of the open source world
already operates in general. Our level of scrutiny is a burden that I
don't see many others sharing.

Of course "everybody's doing it" doesn't make something right. However,
when things go wrong, they don't seem to go wrong in the dramatic ways
we might anticipate them to.

If GitHub (a Microsoft-owned entity and thus an attractive target for a
lawsuit) is OK with distributing files uploaded by third parties without
subjecting them to a manual review process, perhaps we have been
overthinking the risks here.

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Timo Röhling  writes:

> The FTP team review should focus on these types of mistakes, and not
> only with new packages: any "suspicious" upload should be rerouted to a
> POLICY queue for additional verification.  There is some prior art with
> the auto-REJECT on Lintian errors, which could be extended to a
> three-way decision (ACCEPT, POLICY REVIEW, REJECT).

I feel like it would also be a lot easier to get volunteers to look at
packages that had already been flagged, rather than do green-field reviews
of every package everyone uploads (most of which are entirely fine or have
at most minor issues).  It certainly feels like a more interesting problem
to me!  "Here are a few things that looked weird, please manually look at
this package to see if they're a problem."

Or even "this package has maintainer scripts that aren't just
debhelper-generated boilerplate, please look at them and make sure they're
not going to run rm -r / or something crazy."

> For instance, we could flag epoch bumps or major version numbers which
> skip ahead significantly (think 020220101 instead of 0.20220101). We can
> certainly continue to flag new binaries and potential copyright
> violations (e.g., packages with incompatible licenses or files with
> "(?i)(?:do|must) not distribute" in their headers), or anything else we
> consider important. The automated checks need not be perfect as long as
> we avoid false negatives on the critical issues.

Exactly.  We're not going to catch everything, to be sure, but we're not
catching everything *now*, and improvements of automation scale in ways
that trying to do more painstaking human review do not.

-- 
Russ Allbery (r...@debian.org)  

Re: Legal advice regarding the NEW queue

[Timo Röhling]

* Russ Allbery  [2022-02-04 11:48]:

No, that's fine, that's not a strawman argument.  That is, in fact, my
argument: I think it should be okay to put crap packages in the unstable
archive and fix them later, and I would rather put more effort into the
"noticing" part than in the pre-review part.

[...]

Now, all of that being said, I also want to say that I'm sketching out one
end of the argument because I think that end has been underrepresented.  I
don't think this is an all-or-nothing binary choice.  We could, for
example, focus our review on only packages that are viewed as riskier
(only packages with maintainer scripts or that start daemons, for
instance, or stop doing NEW review for packages uploaded under the
auspices of well-established Debian teams, or stop doing NEW review for
shared libraries whose source packages are already in Debian), all of
which would be improvements from my perspective. 

In my opinion, this is a very important train of thought, because
not all crap is created equal. While some things can be fixed easily
with a new upload, others have permanent repercussions, for example:

- It is impossible to undo an epoch bump, or more
  generally, revert to an earlier version number.
- The package namespace can be polluted, or existing names can be
  hijacked, potentially rendering names unusuable
  for future uploads (particularly if the hijacking version number is
  sufficiently large and/or epoch'd).

I'm not implying any ill-will, merely observing that people make
mistakes, and some mistakes are more costly to rectify than others.

The FTP team review should focus on these types of mistakes, and not
only with new packages: any "suspicious" upload should be rerouted
to a POLICY queue for additional verification.  There is some prior
art with the auto-REJECT on Lintian errors, which could be
extended to a three-way decision (ACCEPT, POLICY REVIEW, REJECT).

For instance, we could flag epoch bumps or major version numbers
which skip ahead significantly (think 020220101 instead of
0.20220101). We can certainly continue to flag new binaries and
potential copyright violations (e.g., packages with incompatible
licenses or files with "(?i)(?:do|must) not distribute" in their
headers), or anything else we consider important. The automated
checks need not be perfect as long as we avoid false negatives on
the critical issues. And I imagine it will also speed up the review
considerably if the FTP team already knows what problems (not) to
look for.


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 2:48:50 PM EST Russ Allbery wrote:
> Scott Kitterman  writes:
> > Since we're doing strawman arguments in this thread: I disagree with the
> > notion that it's not a problem to put crap packages in the archive and
> > fix them later if anyone happens to notice.
> 
> No, that's fine, that's not a strawman argument.  That is, in fact, my
> argument: I think it should be okay to put crap packages in the unstable
> archive and fix them later, and I would rather put more effort into the
> "noticing" part than in the pre-review part.
> 
> We may quibble about what "crap" means and we may disagree about how much
> of this potentially could be weeded by automated tools (and I want to be
> very clear that I'm not opposed to automated checks and indeed think we
> should make them stricter), but I think this is a blunt but fair
> characterization of my position.
> 
> To be clear on the nuance I see here, I don't mean that this is "okay" in
> the sense that people should feel fine about doing it.  I think we should
> all aspire to not do that, of course.  But I think it should be "okay" in
> the sense that I don't think we should invest the level of resources we're
> currently investing in trying to avoid it, because I think that's causing
> other significant problems for the project.
> 
> My argument in favor of this position is that while it's very obvious to
> see the harm from having crap packages in the archive, we're overlooking
> the very substantial cost we're paying with our current method of trying
> to reduce the frequency with which this happens.  I think we're
> underestimating just how costly and demoralizing dealing with NEW delays
> is for project work, and also how much of a drain and competition for
> resources that is with other archive work that we could be doing.
> 
> For example, in just the past two months I have seen two *extremely
> experienced* Debian developers who maintain extremely high-quality
> packages express qualms about package architectures that would fix other
> bugs in Debian *solely* because they would force more trips through NEW
> and the trip through NEW is so disruptive to their work that it was at
> least tempting to accept other bugs in order to avoid that disruption.  To
> me, this indicates that we may have our priorities out of alignment.
> 
> Now, all of that being said, I also want to say that I'm sketching out one
> end of the argument because I think that end has been underrepresented.  I
> don't think this is an all-or-nothing binary choice.  We could, for
> example, focus our review on only packages that are viewed as riskier
> (only packages with maintainer scripts or that start daemons, for
> instance, or stop doing NEW review for packages uploaded under the
> auspices of well-established Debian teams, or stop doing NEW review for
> shared libraries whose source packages are already in Debian), all of
> which would be improvements from my perspective.  We could also do some
> parts of NEW review and not others and see if that makes it more
> attractive for other people to volunteer.  (The manual review for
> d/copyright correctness is certainly the part of NEW review that I can't
> imagine volunteering to do, and I suspect I'm not alone.)
> 
> To be clear, as long as the rules in Debian are what they are, I will of
> course follow them as I promised to do when I became a Debian Developer.
> If the project continues to believe that it is of primary importance for
> us to be the copyright notice and license catalog review system for the
> entire free software ecosystem (which is honestly what it feels like we've
> currently decided to volunteer to do on top of our goal of building a
> distribution), then I will do my part with the packages that I upload so
> that I don't put unnecessary load on the folks doing NEW review.  But when
> we've collectively been doing something for so long, we can lose track of
> the fact that it's a choice, and other choices are possible.  It's worth
> revisiting those choices consciously from time to time.

OK.  Fair enough.  I think your assessment of the costs of the current 
approach is reasonable.

I've seen several assertions that more could be done to detect and correct 
problems in the archive, which would make New review less important, but these 
discussions all seem to start with the assertion that we should throw out the 
current system and then something good will happen.  I think that puts the 
cart before the horse.

Personally, if someone had a system that could post-process uploads and 
identify which licenses are in use and if there are any incompatibilities, I 
think that would go a long way towards moving the balance in the direction you 
are advocating for.  Speaking just for myself, packages that are 
undistributable due to lack of licensing or use of incompatible licenses which 
impairs sublicensabiltiy is a large concern.  Whether we drop New or not, I 
think that would be great thing

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Scott Kitterman  writes:

> Since we're doing strawman arguments in this thread: I disagree with the
> notion that it's not a problem to put crap packages in the archive and
> fix them later if anyone happens to notice.

No, that's fine, that's not a strawman argument.  That is, in fact, my
argument: I think it should be okay to put crap packages in the unstable
archive and fix them later, and I would rather put more effort into the
"noticing" part than in the pre-review part.

We may quibble about what "crap" means and we may disagree about how much
of this potentially could be weeded by automated tools (and I want to be
very clear that I'm not opposed to automated checks and indeed think we
should make them stricter), but I think this is a blunt but fair
characterization of my position.

To be clear on the nuance I see here, I don't mean that this is "okay" in
the sense that people should feel fine about doing it.  I think we should
all aspire to not do that, of course.  But I think it should be "okay" in
the sense that I don't think we should invest the level of resources we're
currently investing in trying to avoid it, because I think that's causing
other significant problems for the project.

My argument in favor of this position is that while it's very obvious to
see the harm from having crap packages in the archive, we're overlooking
the very substantial cost we're paying with our current method of trying
to reduce the frequency with which this happens.  I think we're
underestimating just how costly and demoralizing dealing with NEW delays
is for project work, and also how much of a drain and competition for
resources that is with other archive work that we could be doing.

For example, in just the past two months I have seen two *extremely
experienced* Debian developers who maintain extremely high-quality
packages express qualms about package architectures that would fix other
bugs in Debian *solely* because they would force more trips through NEW
and the trip through NEW is so disruptive to their work that it was at
least tempting to accept other bugs in order to avoid that disruption.  To
me, this indicates that we may have our priorities out of alignment.

Now, all of that being said, I also want to say that I'm sketching out one
end of the argument because I think that end has been underrepresented.  I
don't think this is an all-or-nothing binary choice.  We could, for
example, focus our review on only packages that are viewed as riskier
(only packages with maintainer scripts or that start daemons, for
instance, or stop doing NEW review for packages uploaded under the
auspices of well-established Debian teams, or stop doing NEW review for
shared libraries whose source packages are already in Debian), all of
which would be improvements from my perspective.  We could also do some
parts of NEW review and not others and see if that makes it more
attractive for other people to volunteer.  (The manual review for
d/copyright correctness is certainly the part of NEW review that I can't
imagine volunteering to do, and I suspect I'm not alone.)

To be clear, as long as the rules in Debian are what they are, I will of
course follow them as I promised to do when I became a Debian Developer.
If the project continues to believe that it is of primary importance for
us to be the copyright notice and license catalog review system for the
entire free software ecosystem (which is honestly what it feels like we've
currently decided to volunteer to do on top of our goal of building a
distribution), then I will do my part with the packages that I upload so
that I don't put unnecessary load on the folks doing NEW review.  But when
we've collectively been doing something for so long, we can lose track of
the fact that it's a choice, and other choices are possible.  It's worth
revisiting those choices consciously from time to time.

-- 
Russ Allbery (r...@debian.org)  

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 12:39:09 PM EST Russ Allbery wrote:
> The Wanderer  writes:
> > What I read Scott as having been suggesting, by contrast, is that people
> > instead do copyright review for packages already in Debian, which may
> > well have had changes that did not have to pass through NEW and that
> > might not have been able to pass the NEW copyright review.
> > 
> > If a practice of doing that latter were established and sufficiently
> > widespread, then it would not be as important to do the review for every
> > package in NEW, and the FTP team might feel less of a need to insist
> > that the review take place at that stage of things.
> 
> Various people have different reactions to and opinions about the
> necessity of this review, which I understand and which is great for
> broadening the discussion.  But I feel like we're starting to lose track
> of my original point, namely that I don't see why we are prioritizing this
> particular category of bugs over every other type of bug in Debian.  The
> justification has always been dire consequences if we don't stamp out all
> of these bugs, but to be honest I think this is wildly unlikely.
> 
> In other words, this thread is once again drifting into a discussion of
> how to do copyright review *better*, when my original point is that we
> should seriously consider not doing the current type of incredibly tedious
> and nit-picky copyright review *at all*, and instead rely more on
> upstream's assertions, automated tools, and being reactive in solving the
> bugs that people actually care about (i.e., notice).
> 
> In other words, what if, when upstream said "this whole package is covered
> by the MIT license," we just defaulted to believing them?  And if there's
> some file buried in there that's actually covered by the GPL, we fixed
> that when someone brought it to our attention, or when we were able to
> detect it with automated tools, but we didn't ask people to spend hours
> reviewing the license headers on every source file?  What, concretely,
> would go wrong?
> 
> Scott correctly points out that there are a ton of copyright bugs in
> Debian *anyway*, despite NEW review.  He sees this as a reason for not
> relaxing our review standards.  I see it as the exact opposite: evidence
> that our current review standards are not achieving the 100% correctness
> we have claimed to be striving for, and the nearly complete lack of
> practical consequences for that failure.  It really seems to me like
> evidence that this task is not as important as we think it is.

A substantial fraction of packages uploaded to New are not deemed to be 
sufficiently policy compliant to enter the archive.  I don't have numbers, but 
if it was more than a quarter of them, I wouldn't be surprised.  It's true 
that the bulk of that is due to copyright/license issues, but it's not all of 
it.  While most of the severe bugs we find are in this area, that's not all we 
look for.

I disagree with the premise that all DDs can and do create packages of 
sufficient quality that no check point is needed to assess them before they 
enter the archive.  My experience is that this is just not true.  We review a 
lot of genuinely awful stuff that's uploaded even when it's known there will be 
a review in New.

If we kept the New queue in place, but didn't review the correctness of d/
copyright, it would make it faster to review packages, but I don't think it 
makes sense to make that one aspect of policy that the FTP Team decides to 
ignore.  I think most of your argument is with Policy 2.3.

We don't search out the true source/licensing of files in the packages we 
review.  There are cases where the upstream file indicates it was copies from 
elsewhere and the license/copyright attribution is ignored, but generally we 
assume that what is in the package is correct.

Since we're doing strawman arguments in this thread: I disagree with the 
notion that it's not a problem to put crap packages in the archive and fix them 
later if anyone happens to notice.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Embedded buildpath via rpath using cmake

[Vagrant Cascadian]

On 2022-02-04, Seth Arnold wrote:
> On Thu, Feb 03, 2022 at 04:41:21PM -0800, Vagrant Cascadian wrote:
>> Over the last several months, I and others have found quite a few
>> packages that embed build paths via rpath when building with cmake.  I
>> found myself slowly edging into a mass bug filing, one bug report at a
>> time...
>
> Hello Vagrant, does this represent a security problem?

Other than reproducible builds in general providing some security
properties, I would say not really.


> I tried to give this a look myself but didn't know what to look for; I
> grabbed a few recent versions of packages:
>
> http://ftp.debian.org/debian/pool/main/n/nfs-ganesha/nfs-ganesha_3.4-1_amd64.deb

One thing is checking the reproducible builds results:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nfs-ganesha.html

Which appear to have reproducibility issues in the unstable tests, where
build paths are varied, but not in bookworm, where build paths are not
varied.

Unfortunately, the diffoscope output linked above does not obviously
show the build path embedded in the binaries (other than some .py files,
which may be a separate issue).

There are a few lines which are non-obvious, but are in my experience a
sign of different build paths:

  0x000a·(STRSZ)··2327·(bytes)
vs.
  0x000a·(STRSZ)··2329·(bytes)

My going theory is that the length of the build path is embedded in a
padded value, even though the build path itself is actually stripped,
perhaps via -ffile-prefix-map=BUILDPATH=. or similar.


> http://ftp.debian.org/debian/pool/main/v/vmemcache/libvmemcache0_0.8.1-4_amd64.deb
> http://ftp.debian.org/debian/pool/main/f/fontforge/fontforge_20201107~dfsg-4_amd64.deb
>
> $ find . -type f -exec eu-readelf -d {} \; 2>/dev/null | grep RUNPATH
>   RUNPATH   Library runpath: [/usr/lib/ganesha]
>   RUNPATH   Library runpath: [/usr/lib/ganesha]
>   RUNPATH   Library runpath: [/usr/lib/ganesha]
>   RUNPATH   Library runpath: [/usr/lib/ganesha]
>
> Am I on the wrong track?

Because it doesn't often leave obvious traces of the build path in the
binaries, it is a bit tricky to test simply by examining the binaries
directly... Instead, experimentation seems to be the best way.

I use reprotest for this, first running a build with reprotest without
the patch, confirming that it builds at all, and does not build
reproducibly. Then running reprotest with the patch applied to add
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON in debian/rules, and seeing if it
builds reproducibly.

From the source directory, with the build dependencies installed:

  reprotest --verbose --store-dir=$(mktemp -d $HOME/buildresults-XX) 
--vary=-all,+build_path -- null


This should normalize the build as much as possible so that the only
thing different between the two builds is the build path.

Then compare the resulting buildresults-*/*.out to see if the second
build produces significantly less diffoscope output...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Russ Allbery]

The Wanderer  writes:

> What I read Scott as having been suggesting, by contrast, is that people
> instead do copyright review for packages already in Debian, which may
> well have had changes that did not have to pass through NEW and that
> might not have been able to pass the NEW copyright review.

> If a practice of doing that latter were established and sufficiently
> widespread, then it would not be as important to do the review for every
> package in NEW, and the FTP team might feel less of a need to insist
> that the review take place at that stage of things.

Various people have different reactions to and opinions about the
necessity of this review, which I understand and which is great for
broadening the discussion.  But I feel like we're starting to lose track
of my original point, namely that I don't see why we are prioritizing this
particular category of bugs over every other type of bug in Debian.  The
justification has always been dire consequences if we don't stamp out all
of these bugs, but to be honest I think this is wildly unlikely.

In other words, this thread is once again drifting into a discussion of
how to do copyright review *better*, when my original point is that we
should seriously consider not doing the current type of incredibly tedious
and nit-picky copyright review *at all*, and instead rely more on
upstream's assertions, automated tools, and being reactive in solving the
bugs that people actually care about (i.e., notice).

In other words, what if, when upstream said "this whole package is covered
by the MIT license," we just defaulted to believing them?  And if there's
some file buried in there that's actually covered by the GPL, we fixed
that when someone brought it to our attention, or when we were able to
detect it with automated tools, but we didn't ask people to spend hours
reviewing the license headers on every source file?  What, concretely,
would go wrong?

Scott correctly points out that there are a ton of copyright bugs in
Debian *anyway*, despite NEW review.  He sees this as a reason for not
relaxing our review standards.  I see it as the exact opposite: evidence
that our current review standards are not achieving the 100% correctness
we have claimed to be striving for, and the nearly complete lack of
practical consequences for that failure.  It really seems to me like
evidence that this task is not as important as we think it is.

-- 
Russ Allbery (r...@debian.org)  

Re: Embedded buildpath via rpath using cmake

[Vagrant Cascadian]

On 2022-02-04, Paul Wise wrote:
> Vagrant Cascadian wrote:
>
>> Over the last several months, I and others have found quite a few
>> packages that embed build paths via rpath when building with cmake.
>
> This seems like the sort of thing that will be an ongoing problem, so
> if it is detectable statically then a lintian warning might be good.

So far I have only figured out how to detect it by building packages and
checking if they're reproducible, but if someone can figure out how to
make it work from lintian, so much the better!

I believe there is a lintian check for build paths embedded in binaries,
at least, which will catch this and other issues, but maybe it could be
extended to check for this more explicitly...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: IPv6-only testing

[Jakub Wilk]

* Jakub Wilk , 2022-02-04, 15:38:

unshare -c -r --keep-caps


Oops, I meant "unshare -n -r --keep-caps".


$ python3 -c 'from socket import *; getaddrinfo("127.0.0.1", port=1, 
flags=AI_ADDRCONFIG)'


Note that the above does not fail when only loopback is configured, so 
it seems to be something else than #952740.


I haven't figured out what's exactly going on in #1004461, because the 
package FTBFS for me in a different way that I don't understand. :-/


--
Jakub Wilk

Re: Rakudo has a transition tracker and then what ?

[M. Zhou]

Hi Sebastian,

Building the files upon installation is exactly the original
behavior. The problem is that compilation speed is too slow.
Three raku packages could take more than 2 minutes every
time when there is a raku upgrade to any version.

On Fri, 2022-02-04 at 13:55 +0100, Sebastian Ramacher wrote:
> On 2022-02-03 17:58:24, M. Zhou wrote:
> > @dod: It looks that we have to change the Architecture: of raku-*
> > packages into any (instead of "all") because there is no binnmu
> > for Arch:all package. Then upon each time we bump the rakudo API
> > version, we just need to file a regular transition bug to the
> > release team and trigger the rebuild.
> 
> If the pre-compiled files are like pyc files for Python, is there are
> a
> reason to not follow the same approach? That is, build the pre-
> compiled
> files on install.
> 
> Cheers
> 
> > 
> > On Thu, 2022-02-03 at 19:13 +0100, Jonas Smedegaard wrote:
> > > Quoting Paul Gevers (2022-02-03 19:08:34)
> > > > On 03-02-2022 18:53, Dominique Dumont wrote:
> > > > > Hoping to automate this process, I've setup a transition
> > > > > tracker
> > > > > for Rakudo
> > > > > [1].
> > > > 
> > > > See
> > > > https://lists.debian.org/debian-release/2022/02/msg00029.html a
> > > > nd 
> > > > follow-up messages.
> > > 
> > > As I understand it, librust-* packages are released as arch:any
> > > (not 
> > > arch:all) for this exact reason (I seem to recall some discussion
> > > with 
> > > the ftpmaster and/or release team about that - evidently leading
> > > to
> > > that 
> > > praxis being tolerated, except I am totally wrong and the cause
> > > for
> > > Rust 
> > > is a different one).
> > > 
> > > 
> > >  - Jonas
> > > 
> > 
> > 
> 

Re: IPv6-only testing

[Simon McVittie]

On Fri, 04 Feb 2022 at 15:38:12 +0100, Jakub Wilk wrote:
> * Julien Puydt , 2022-02-04, 12:34:
> > I got an RC bug on python-anyio, because its testsuite fails when run on
> > an IPv6-only host [1].
> 
> I'm pretty sure "IPv6-only" means "the only non-loopback addresses this host
> has are IPv6", rather than "it doesn't have any IPv4, not even 127.0.0.1."
> 
> This project uses AI_ADDRCONFIG: "IPv4 addresses are returned […] if the
> local system has at least one IPv4 address configured, […] The loopback
> address is not considered for this case as valid as a configured address."
> 
> Somewhat surprisingly, this means that getaddrinfo("127.0.0.1", ...) can
> fail even when the 127.0.0.1 address exists.

See also: https://bugs.debian.org/952740, which I reported as a result
of the equivalent bug being reported for dbus.

smcv

Re: DD(s) to help DM land some long-overdue package updates?

[Reuben Thomas]

On Sat, 1 Jan 2022 at 22:34, Reuben Thomas  wrote:

> On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue  wrote:
> >
> > I suggest this path:
> >
> > Send bug reports with your debdiff proposals for each package. If 8 days
> > after you get no reply from the maintainer, file an ITS against the
> > packages for which you got no reply.
> >
> > If at the end of the process, the ITS pass, I'll make your uploads
> > after reviewing the changes.
>
> Many thanks, I'll try to do this.
>

I thought I should give an update on my progress: Santiago Vila started
work on packaging recode 3.7, one of the packages I mentioned, so I did
some work to help with that. That has actually taken most of my time until
now.

However, I have also found some time to work on the packaging of mmv. I
think this is one of the clearest-cut packages in the list I mentioned: I
am the (new) upstream of mmv, and I have made a new release.

Having just now got the new Debian packaging building without error, I
shall now follow the ITS procedure and see what happens!

-- 
https://rrt.sc3d.org

Bug#1004969: ITP: commandlines -- Python library for command line application development

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: commandlines
  Version : 0.4.1
  Upstream Author : Christopher Simpkins 
* URL : https://github.com/chrissimpkins/commandlines
* License : MIT/X
  Programming Lang: Python
  Description : Python library for command line application development

 Commandlines is a Python library for command line application development that
 supports command line argument parsing, command string validation testing, &
 application logic. It has no external dependencies and provides broad Python
 interpreter support for Python 2.6+, Python 3.3+, pypy, and pypy3.
 .
 The library supports application development with POSIX guideline compliant[*]
 command argument styles, the GNU argument style extensions to the POSIX
 guidelines (including long option syntax and variable position of options
 among arguments), and command suite style application arguments that include
 one or more sub-commands to the executable.

Re: IPv6-only testing

[Jakub Wilk]

* Julien Puydt , 2022-02-04, 12:34:
I got an RC bug on python-anyio, because its testsuite fails when run 
on an IPv6-only host [1].


I'm pretty sure "IPv6-only" means "the only non-loopback addresses this 
host has are IPv6", rather than "it doesn't have any IPv4, not even 
127.0.0.1."


This project uses AI_ADDRCONFIG: "IPv4 addresses are returned […] if the 
local system has at least one IPv4 address configured, […] The loopback 
address is not considered for this case as valid as a configured 
address."


Somewhat surprisingly, this means that getaddrinfo("127.0.0.1", ...) can 
fail even when the 127.0.0.1 address exists.


To reproduce this, unshare the network ("unshare -c -r --keep-caps" or 
"sudo unshare -n") and run:


$ ip link set lo up

$ ip link add dum0 type dummy

$ ip link set dum0 up

$ ip -br addr
lo   UNKNOWN127.0.0.1/8 ::1/128
dum0 UNKNOWNfe80::50aa:f3ff:fe1a:e828/64

$ python3 -c 'from socket import *; getaddrinfo("127.0.0.1", port=1, 
flags=AI_ADDRCONFIG)'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -9] Address family for hostname not supported

--
Jakub Wilk

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 4:00:44 AM EST Philip Hands wrote:
> Scott Kitterman  writes:
> 
> ...
> 
> > My impression is that people are tired of waiting on New, but no one
> > really seems to be interested in doing any work on any alternative
> > other than more bugs.
> 
> Part of the problem is that New processing is a bit of a black box, so
> it's not clear to those of us outside the team how we could help.
> 
> (or at least, not clear to me -- links welcome).
> 
> As a random example, I noticed John Goerzen's post[1] about Yggdrasil on
> planet.d.o last month. John has since uploaded a package.
> 
> As I write it's still in New[2], which is no great shock, as it's only
> been a couple of weeks.
> 
> I'm quite keen to give it a spin.
> 
> So, what can we do with that enthusiasm:
> 
>   I could grab the source and build it locally.
> 
>   I could squander my enthusiasm by waiting for New.
> 
>   I could complain about not being able to download from New, and if if
>   the FTP team listened to me, the enthusiasm would immediately become
>   unavailable to others, as I'd not be feeling frustrated any more.
> 
>   If I knew how to do it, and there were some obvious method, I could
>   contribute to reviewing the package I want to see in the archive.
> 
> On reflection, I think that removing the bottle-neck of New would be a
> mistake, as it would the remove the itch we all want to scratch.
> 
> Instead please just provide us with the ability to scratch that itch and
> you may find that you suddenly have quite a few more volunteers.
> 
> In the example above, eventually I will get sufficiently bored of
> waiting to build the package myself, which will probably be rather more
> effort than reviewing it would have been, so I'd much rather be able to
> apply that effort in a way that benefits more than just me.

I think that all makes sense.  Currently the only answer is join the FTP Team 
as a trainee when there is a call for volunteers.  I totally get the 
frustration.

I'm not sure how much value there is in drive-by reviews as a general case.  I 
suppose if external reviews were done it could identify reject cases that 
would mean the FTP Team could spend more time on packages that might be 
accepted.  I don't expect an external review that said "It's fine, recommend 
you accept it" would cause any FTP Team member to blindly accept the package.

I'll consider if there's not perhaps some middle ground so that we can see if 
there are enough volunteers to make a dent in things.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Legal advice regarding the NEW queue

[The Wanderer]

On 2022-02-04 at 04:00, Philip Hands wrote:

> Scott Kitterman  writes:
> 
> ...
>> My impression is that people are tired of waiting on New, but no
>> one really seems to be interested in doing any work on any
>> alternative other than more bugs.
> 
> Part of the problem is that New processing is a bit of a black box,
> so it's not clear to those of us outside the team how we could help.
> 
> (or at least, not clear to me -- links welcome).
> 
> As a random example, I noticed John Goerzen's post[1] about Yggdrasil
> on planet.d.o last month. John has since uploaded a package.
> 
> As I write it's still in New[2], which is no great shock, as it's
> only been a couple of weeks.

If I read your response (and Andrei's) correctly, you're approaching
this in terms of providing copyright reviews for packages waiting in
NEW, to relieve some of the burden on the FTP team and speed up the
processing of those packages through NEW.

What I read Scott as having been suggesting, by contrast, is that people
instead do copyright review for packages already in Debian, which may
well have had changes that did not have to pass through NEW and that
might not have been able to pass the NEW copyright review.

If a practice of doing that latter were established and sufficiently
widespread, then it would not be as important to do the review for every
package in NEW, and the FTP team might feel less of a need to insist
that the review take place at that stage of things.

> On reflection, I think that removing the bottle-neck of New would be
> a mistake, as it would the remove the itch we all want to scratch.
> 
> Instead please just provide us with the ability to scratch that itch
> and you may find that you suddenly have quite a few more volunteers.

I do, however, concur with these sentiments. Expanding the sphere of
those who can to provide reviews (if not necessarily grant approvals) to
packages in NEW might well be a good idea.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Embedded buildpath via rpath using cmake

[David Prévot]

Hi,

Le 04/02/2022 à 08:58, Andreas Ronnquist a écrit :

On Thu, 03 Feb 2022 16:41:21 -0800,
Vagrant Cascadian wrote:



If you're on the list, would love if you could check if your package
still builds correctly when passing only
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON.  For a few of the packages, there
are already patches in the Debian bug tracking system waiting for you!


allegro5 builds fine here when adding -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON.


Ditto for cmocka.

Is there a better place than this debian-devel thread to document what 
works or not?


Regards

David

Re: Embedded buildpath via rpath using cmake

[Andreas Ronnquist]

On Thu, 03 Feb 2022 16:41:21 -0800,
Vagrant Cascadian wrote:
>
>I've attached a list of the maintainers of affected packages produced
>with dd-list, getting the list of packages from the above-mentioned
>reproducible builds issue and diff.dcsr.txt from archive rebuild.
>
>If you're on the list, would love if you could check if your package
>still builds correctly when passing only
>-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON.  For a few of the packages, there
>are already patches in the Debian bug tracking system waiting for you!
>

allegro5 builds fine here when adding -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON.

-- Andreas Rönnquist
mailingli...@gusnan.se
gus...@debian.org


pgpNZ3VqoXFHr.pgp
Description: OpenPGP digital signatur

Re: Rakudo has a transition tracker and then what ?

[Sebastian Ramacher]

On 2022-02-03 17:58:24, M. Zhou wrote:
> @dod: It looks that we have to change the Architecture: of raku-*
> packages into any (instead of "all") because there is no binnmu
> for Arch:all package. Then upon each time we bump the rakudo API
> version, we just need to file a regular transition bug to the
> release team and trigger the rebuild.

If the pre-compiled files are like pyc files for Python, is there are a
reason to not follow the same approach? That is, build the pre-compiled
files on install.

Cheers

> 
> On Thu, 2022-02-03 at 19:13 +0100, Jonas Smedegaard wrote:
> > Quoting Paul Gevers (2022-02-03 19:08:34)
> > > On 03-02-2022 18:53, Dominique Dumont wrote:
> > > > Hoping to automate this process, I've setup a transition tracker
> > > > for Rakudo
> > > > [1].
> > > 
> > > See
> > > https://lists.debian.org/debian-release/2022/02/msg00029.html and 
> > > follow-up messages.
> > 
> > As I understand it, librust-* packages are released as arch:any (not 
> > arch:all) for this exact reason (I seem to recall some discussion
> > with 
> > the ftpmaster and/or release team about that - evidently leading to
> > that 
> > praxis being tolerated, except I am totally wrong and the cause for
> > Rust 
> > is a different one).
> > 
> > 
> >  - Jonas
> > 
> 
> 

-- 
Sebastian Ramacher

IPv6-only testing

[Julien Puydt]

Hi,

I got an RC bug on python-anyio, because its testsuite fails when run
on an IPv6-only host [1].

I pushed the issue upstream, and upstream has a patch proposal [2].

Now comes the question: how do I test this patch?

Cheers,

J.Puydt

[1] https://bugs.debian.org/1004461
[2] https://github.com/agronholm/anyio/issues/417

Re: Embedded buildpath via rpath using cmake

[Roland Clobus]

On 04/02/2022 11:58, Simon McVittie wrote:

For packages where the RPATH or RUNPATH is temporarily set during build
(to be able to run unit tests without setting LD_LIBRARY_PATH) but then
removed before installation with `chrpath -d` or equivalent code in CMake,
I don't think this is going to be detectable statically, because the
only traces left in the final binary are:

- the build-ID will be different, because the RPATH/RUNPATH was part of
   the data that gets hashed to create the build-ID
- if the length of the build directory changes, then the block of zero
   bytes that previously contained the RPATH/RUNPATH (before it was
   overwritten) will have a different length


I've written a detection for this build-ID mismatch in diffoscope some 
time ago. [1]


It does not require two builds to detect a mismatched NT_GNU_BUILD_ID, 
so perhaps it make sense to migrate this code to lintian (in addition to 
the already mentioned 'custom-library-search-path'. [2]


With kind regards,
Roland Clobus

[1] 
https://sources.debian.org/src/diffoscope/202/diffoscope/comparators/elf.py/?hl=646#L646

[2] https://lintian.debian.org/tags/custom-library-search-path


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004960: ITP: cmyt -- Matplotlib colormaps from the yt project

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: cmyt
  Version : 1.0.4
  Upstream Author : Clement Robert
* URL : https://github.com/yt-project/cmyt
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Matplotlib colormaps from the yt project

cmyt integrates with matplotlib in a similar fashion to cmocean or cmasher

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/cmyt

Best regards

Ole

Bug#1004958: ITP: xraydb -- X-ray Reference Data

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 
X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org

* Package name: xraydb
  Version : 4.4.7
  Upstream Author : Matthew Newville 
* URL : https://github.com/xraypy/XrayDB
* License : Public domain
  Programming Lang: Python
  Description : X-ray Reference Data

X-ray Reference Data in SQLite library, including a Python3
interface. The database contains data about the interactions
of X-rays with matter.

xraydb is needed as a build-dependency of xraylarch (ITP #949126)
xraydb will be maintained by the Debian PaN Maintainers
as part of the Debian Science Team.

Re: Embedded buildpath via rpath using cmake

[Simon McVittie]

On Fri, 04 Feb 2022 at 13:07:53 +0800, Paul Wise wrote:
> Vagrant Cascadian wrote:
> > Over the last several months, I and others have found quite a few
> > packages that embed build paths via rpath when building with cmake.
> 
> This seems like the sort of thing that will be an ongoing problem, so
> if it is detectable statically then a lintian warning might be good.

For packages that (intentionally or unintentionally) still have a RPATH
or RUNPATH in their installed files,
https://lintian.debian.org/tags/custom-library-search-path detects it.
You'll see that many of them are overridden as being necessary and
intentional.

For packages where the RPATH or RUNPATH is temporarily set during build
(to be able to run unit tests without setting LD_LIBRARY_PATH) but then
removed before installation with `chrpath -d` or equivalent code in CMake,
I don't think this is going to be detectable statically, because the
only traces left in the final binary are:

- the build-ID will be different, because the RPATH/RUNPATH was part of
  the data that gets hashed to create the build-ID
- if the length of the build directory changes, then the block of zero
  bytes that previously contained the RPATH/RUNPATH (before it was
  overwritten) will have a different length

This is the sort of thing that can probably only be detected by literally
doing two builds (in different directories) and comparing them with
diffoscope, or possibly by screen-scraping build logs like blhc does.

smcv

Re: Embedded buildpath via rpath using cmake

[Simon McVittie]

On Fri, 04 Feb 2022 at 02:23:54 +, Seth Arnold wrote:
> does this represent a security problem?

"It depends". (This answer is not specific to CMake, it's equally valid
for any build system.)

If the RPATH or RUNPATH points to a trusted directory where write access
would require root-equivalent privileges, such as somewhere below /usr,
then it's not a problem.

Some packages have to do this in order to access private shared libraries,
which sounds like a contradiction, but isn't really. Some libraries
are not sufficiently API- or ABI-stable to be suitable to place them
in the global search path for the OS as a whole, but do need to be
shared between a closely cooperating group of programs, either within a
single package or in several tightly-coupled packages.

For example, lots of small programs in the systemd package are linked to
/lib/systemd/libsystemd-shared-250.so, which contains code that is shared
between those programs but is not a stable public API. Statically linking
that shared code would have resulted in a separate partial copy in every
program, which would have made the package much larger, so instead it
is a private shared library; and to make that work, the programs have
a RUNPATH pointing to /lib/systemd.

This RUNPATH is not a security problem with systemd, because to be
able to exploit it to make these programs execute arbitrary code, an
attacker would need to be able to write to /lib/systemd - but if the
attacker can write to /lib/systemd (or, more generally, /usr or /lib),
then system integrity has already failed.

Having a RUNPATH set to /usr/lib/ganesha looks like it is similar to
the systemd case. If it's intentional, then it's almost certainly fine.

The situation where a RPATH or RUNPATH *does* represent a security problem
is when the RPATH or RUNPATH points to a directory that might become
attacker-controlled. For example, if the RUNPATH of a program "foobar" is
set to its build directory in /tmp, perhaps /tmp/foobar_1.0_59PnHH,
then an attacker could create that directory, put their malicious code
into it, and wait for the victim to run foobar.

Similarly, if the RUNPATH is /home/fred/builds/foobar-1.0, then
that isn't a practical problem for most people, but if you happen to
have an untrusted local user whose home directory is /home/fred, it
becomes a security vulnerability on that particular system.

There is a third situation referenced by
https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html,
which is not a security problem, but is a reproducibility problem. It's
common for executables and libraries to be given a temporary RUNPATH
pointing to the location of shared libraries in the build directory, so
that unit tests can be run before the package is installed without needing
to set the LD_LIBRARY_PATH (in Autotools, this is the --disable-fast-install
option; in CMake, it seems to be the default). CMake removes the RUNPATH
just before installation, so it doesn't become a security problem,
but that's too late to stop it from affecting the build-ID - and the
*length* of the build directory can also affect the contents of the
binary, because when RUNPATHs are removed, it is done by overwriting
them with zeroes in-place, leaving a run of zeroes with the same length
as the removed RUNPATH.

smcv

Re: Legal advice regarding the NEW queue

[Philip Hands]

Scott Kitterman  writes:

...
> My impression is that people are tired of waiting on New, but no one
> really seems to be interested in doing any work on any alternative
> other than more bugs.

Part of the problem is that New processing is a bit of a black box, so
it's not clear to those of us outside the team how we could help.

(or at least, not clear to me -- links welcome).

As a random example, I noticed John Goerzen's post[1] about Yggdrasil on
planet.d.o last month. John has since uploaded a package.

As I write it's still in New[2], which is no great shock, as it's only
been a couple of weeks.

I'm quite keen to give it a spin.

So, what can we do with that enthusiasm:

  I could grab the source and build it locally.

  I could squander my enthusiasm by waiting for New.

  I could complain about not being able to download from New, and if if
  the FTP team listened to me, the enthusiasm would immediately become
  unavailable to others, as I'd not be feeling frustrated any more.

  If I knew how to do it, and there were some obvious method, I could
  contribute to reviewing the package I want to see in the archive.

On reflection, I think that removing the bottle-neck of New would be a
mistake, as it would the remove the itch we all want to scratch.

Instead please just provide us with the ability to scratch that itch and
you may find that you suddenly have quite a few more volunteers.

In the example above, eventually I will get sufficiently bored of
waiting to build the package myself, which will probably be rather more
effort than reviewing it would have been, so I'd much rather be able to
apply that effort in a way that benefits more than just me.

I fully expect the act of building my own package to precede the package
passing New by about a day :-/I think this is a pretty depressing
scenario, which dampens the enthusiasm of all involved on each repeat.

Cheers, Phil.

[1] 
https://changelog.complete.org/archives/10319-make-the-internet-yours-again-with-an-instant-mesh-network

[2] https://ftp-master.debian.org/new/yggdrasil_0.4.2-1.html
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Andrei POPESCU]

On Jo, 03 feb 22, 18:55:44, Scott Kitterman wrote:
> On Thursday, February 3, 2022 2:40:08 PM EST Phil Morrell wrote:
> > 
> > That is not the challenge being made here. I don't believe anyone is
> > arguing that licensing documentation bugs would be anything other than
> > RC bugs according to policy §2.3, just that NEW processing is not the
> > only possible mitigation for the Debian project's legal risk.
> 
> Right, but my point is that anyone who wants to work on identifying licensing 
> and copyright documentation issues in the archive is free to do so today.  
> Anyone can file them and, given appropriate deference to the NMU procedures, 
> anyone can fix them.  Nothing the FTP Team is doing or not doing prevents 
> that.

From the outside (non-DD, lurking for 15 years or so) the FTP Team 
appears to be adamant that the current process is The Only True Way to 
do copyright review.
 
> If someone thinks that there is a viable alternate method, then they should 
> demonstrate it.  You do not need anyone's permission.

Without a clear statement from the FTP Team that alternative copyright 
review processes might even be considered there is very little 
motivation for anyone to even start working on it.

The start could be something as simple as "we (the FTP Team) will 
prioritise packages in NEW that have at least $number of reviews from 
other DDs".

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature