Re: New supply-chain security tool: backseat-signed

[Sean Whitton]

Hello,

On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:

>
> Right now the preferred form of source in Debian is an upstream-signed
> release tarball, NOT anything from git.

The preferred form of modification is not simply up for proclamation.
Our practices, which are focused around git, make it the case that
salsa & dgit in some combination are the preferred form for modification
for most packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Sean Whitton]

Hello,

On Fri 05 Apr 2024 at 03:19pm +01, Simon McVittie wrote:

> There are basically three dgit-compatible workflows, with some minor
> adjustments around handling of .gitignore files:
>
> - "patches applied" (git-debrebase, etc.):
>   This is the workflow that proponents of dgit sometimes recommend,
>   and dgit uses it as its canonicalized internal representation of
>   the package.
>   The git tree is the same as `dpkg-source -x`, with upstream source code
>   included, debian/ also included, and any Debian delta to the upstream
>   source pre-applied to those source files.
>   In the case of bubblewrap, if we used this workflow, after you clone
>   the project, bubblewrap.c would already have the Debian-specific error
>   message.
>   (dgit --split-view=never or dgit --quilt=dpm)
>
> - "patches unapplied" (gbp pq, quilt, etc.):
>   This is the workflow that many of the big teams use (at least Perl,
>   Python, GNOME and systemd), and is the one that bubblewrap really uses.
>   The git tree is the same as `dpkg-source -x --skip-patches`, with
>   upstream source code included, and debian/ also included.
>   Any Debian delta to the upstream source is represented in debian/patches
>   but is *not* pre-applied to the source files: for example, in the case
>   of bubblewrap, after you clone
>   https://salsa.debian.org/debian/bubblewrap.git and view bubblewrap.c,
>   it still has the upstream error message, not the Debian-specific one.
>   (dgit --quilt=gbp or dgit --quilt=unapplied; I use the latter)
>
> - debian/ only:
>   This is what you're advocating above.
>   The git tree contians only debian/. If there is Debian delta to the
>   upstream source, it is in debian/patches/ as usual.
>   (dgit --quilt=baredebian* family)

People interested in these differences may also want to look at:
.

>
> Again, checking for that error is something that can be (and is)
> automated: I use this workflow myself (e.g. in bubblewrap), so I know from
> experience that dgit *does* check for that error, and will fail to build
> the source package if the invariant does not hold. Again, dpkg-source
> in 3.0 (quilt) format will also make your source package fail to build
> if that error exists, except in the cases that it intentionally ignores.

Right, both dgit and tag2upload's client-side wrapped of git-tag(1),
git-debpush(1), do this check.  

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)

[James Addison]

Thanks for the response!

On Fri, 5 Apr 2024 11:12:33 +0200, Guillem wrote:
> On Wed, 2024-04-03 at 23:53:56 +0100, James Addison wrote:
> > On Wed, 3 Apr 2024 19:36:33 +0200, Guillem wrote:
> > > On Fri, 2024-03-29 at 23:29:01 -0700, Russ Allbery wrote:
> > > > On 2024-03-29 22:41, Guillem Jover wrote:
> > > > I think with my upstream hat on I'd rather ship a clear manifest 
> > > > (checked
> > > > into Git) that tells distributions which files in the distribution 
> > > > tarball
> > > > are build artifacts, and guarantee that if you delete all of those 
> > > > files,
> > > > the remaining tree should be byte-for-byte identical with the
> > > > corresponding signed Git tag.  (In other words, Guillem's suggestion.)
> > > > Then I can continue to ship only one release artifact.
> > >
> > > I've been pondering about this and I think I might have come up with a
> > > protocol that to me (!) seems safe, even against a malicious upstream. And
> > > does not require two tarballs which as you say seems cumbersome, and makes
> > > it harder to explain to users. But I'd like to run this through the list
> > > in case I've missed something obvious.

Ok, after a bit more time to process the details, this makes more sense to me
now.  It's a fairly strong assertion about the precise VCS origin and commit
that a _subset_ of the files in a dist tarball originate from.

And the strength of the claim (I think) varies based on how feasible it would
be for an attacker to take control of the origin and write a substitute commit
with the same VCS commit ID and file list - so it's based on fairly
well-understood principles about crytographic hash strength.

(this seems similar in some ways to the existing .dsc file format, although
in relation to a 'source package source' and not sources of binary packages)

In any case: I'm reasonably convinced that the provenance (claim-of-origin)
that this would provide for a source tarball is fairly strong.  That's not my
only concern though (in particular, goto: regeneration).

> > Does this cater for situations where part of the preparation of a source
> > tarball involves populating a directory with a list of filenames that
> correspond to hostnames known to the source preparer?
> >
> > If that set of hostnames changes, then regardless of the same source
> > VCS checkout being used, the resulting distribution source tarball could
> > differ.
>
> > Yes, it's a hypothetical example; but given time and attacker patience,
> > someone is motivated to attempt any workaround.  In practice the
> > difference could be a directory of hostnames or it could be a bitflag
> > that is part of a macro that is only evaluated under various nested
> > conditions.
>
> I'm not sure whether I've perhaps misunderstood your scenario, but if
> the distributed tarball contains things not present in the VCS, then
> with this proposal those can then be easily removed, which means it
> does not matter much if they differ between same tarball generation
> (I mean it matters in the sense that it's an alarm sign, but it does
> not matter in the sense that you can get at the same state as with a
> clean VCS checkout).

Yep, you managed to translate my baffling scenario description into a clearer
problem statement :)

> The other part then is whether the remaining contents differ from what
> is in the VCS.
>
> If any of these trigger a difference, then that would require manual
> review. That of course does not exempt one from reviewing the VCS, it
> just potentially removes one avenue for smuggling artifacts.

Why not reject an upload automatically if a difference is detected between the
source package source and the dist tarball?

> > To take a leaf from the Reproducible Builds[1] project: to achieve a
> > one-to-one mapping between a set of inputs and an output, you need to
> > record all of the inputs; not only the source code, but also the build
> > environment.
> >
> > I'm not yet convinced that source-as-was-written to 
> > distributed-source-tarball
> > is a problem that is any different to that of distributed-source-tarball to
> > built-package.  Changes to tooling do, in reality, affect the output of
> > build processes -- and that's usually good, because it allows for
> > performance optimizations.  But it also necessitates the inclusion of the
> > toolchain and environment to produce repeatable results.
>
> In this case, the property you'd gain is that you do not need to trust
> the system of the person preparing the distribution tarball, and can
> then regenerate those outputs from (supposedly) good inputs from both
> the distribution tarball, and _your_ (or the distribution) system
> toolchain.

regeneration:

Here is the problem.  Let's say that in future with this transparency code in
place, a security bug is discovered in versions of autotools that were
available in the testing or unstable distributions (and may have been used by
some Debian maintainers/developers).  It could be useful to determine a 

Re: New supply-chain security tool: backseat-signed

[Adrian Bunk]

On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
> Hello,
> 
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
> 
> >
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
> 
> The preferred form of modification is not simply up for proclamation.
> Our practices, which are focused around git, make it the case that
> salsa & dgit in some combination are the preferred form for modification
> for most packages.

You cannot simply proclaim that some git tree is the preferred form of 
modification without shipping said git tree in our ftp archive.

If your claim was true, then Debian and downstreams would be violating 
licences like the GPL by not providing the preferred form of modification
in the archive.

> Sean Whitton

cu
Adrian

Re: New supply-chain security tool: backseat-signed

[Guillem Jover]

Hi!

On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote:
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
> 
> The preferred form of modification is not simply up for proclamation.
> Our practices, which are focused around git, make it the case that
> salsa & dgit in some combination are the preferred form for modification
> for most packages.

People keep bringing this up, and it keeps making no sense. I've
covered this over the years in:

  https://lists.debian.org/debian-devel/2014/03/msg00330.html
  https://lists.debian.org/debian-project/2019/07/msg00180.html

(There's in addition the part that Adrian covers in another reply.)

Thanks,
Guillem

Bug#1068505: RFH: reprepro -- Move experimental multi-version feature to unstable

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: affects -1 src:reprepro

Hi,

To tackle the much-requested #570623 multiple version management in reprepro, I took over Maintainership of the package 
and integrated the existing work in experimental. There are three important bugs that were filed against it that need to 
be fixed to finally merge that work to unstable. The bugs are


#1051537
#1016111
#1017983

One of them is surely a big endian-only bug, the other ones are database 
consistency problems that might be related.

As many in the Debian world depend on reprepro to manage their repositories, I would like to ask for help because I did 
not have the capacity in the last two years (and probably not in the remaining year to come during the trixy cycle) to 
give those bugs the attention that they deserve.


Thanks for your help,
Bastian

Re: New supply-chain security tool: backseat-signed

[kpcyrd]

On 4/6/24 1:42 PM, Adrian Bunk wrote:

You cannot simply proclaim that some git tree is the preferred form of
modification without shipping said git tree in our ftp archive.

If your claim was true, then Debian and downstreams would be violating
licences like the GPL by not providing the preferred form of modification
in the archive.


I'm obviously not a lawyer, but I do think this is the case. Quoting 
from GPL-3.0:


> The “source code” for a work means the preferred form of the work for 
making modifications to it. “Object code” means any non-source form of a 
work.


autotools pre-processed source code is clearly not "the preferred form 
of the work for making modifications", which is specifically what I'm 
saying Debian shouldn't consider a "source code input" either, to 
eliminate this vector for underhanded tampering that Jia Tan has used.


If we can force a future Jia Tan to commit their backdoor into git (for 
everybody to see) I consider this a win.


> The “Corresponding Source” for a work in object code form means all 
the source code needed to generate, install, and (for an executable 
work) run the object code and to modify the work, including scripts to 
control those activities.


The GPL is big on "if you ship object files, the source code for them 
better also be available".


The GPL specifically allows me to have private forks, as long as I'm not 
publicly distributing binaries. If I do distribute binaries, I need to 
also publish the source code I derived them from.


Again: The source code needed to build the binaries.

It does not require me to disclose some version control graph, but I do 
need to provide all source code that goes into the build (which is what 
.orig.tar.xz is supposed to be).


A "source code build process" is clearly just the build process in a 
trenchcoat.


cheers,
kpcyrd

Re: xz backdoor

[Michael Shuler]

On 4/5/24 10:30, Pierre-Elliott Bécue wrote:

Pierre-Elliott Bécue  wrote on 31/03/2024 at 14:31:37+0200:

Wookey  wrote on 31/03/2024 at 04:34:00+0200:


On 2024-03-30 20:52 +0100, Ansgar 🙀 wrote:

Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
Possibly also TPM modules in computers.

These can usually be used for both OpenPGP and SSH keys.


Slightly off-topic, but a couple of recent posts have given me the
same thought:

Can someone point to good docs on this?  I've had a yubikey for 3/4 of
a year now but have not yet worked out how I put my GPG key in it. (or
if it should be another key, or a subkey, or whatever). So I'm not
actually using it yet.

PEB also described what sounded like a very sensible way to manage
keys (using subkeys) in one of these threads but I don't know how to
do that myself.


I have started (and never finished) a blog article on how I use my
YubiKey and what config I put in it. I'll definitely try to get it out
before the end of next week. I'll probably extend it to mention the
creation of GPG subkeys etc.

I would also be happy if it helps my fellow DDs to try making an article
about some basic crypto concepts regarding PGP, RSA et al. But not in
the same piece I guess.


Hello,

For those interested in: I've published two articles:

  1. One on PGP subkeys https://pe.becue.phd/openpgp-subkeys
  2. One on the OpenPGP module of YubiKeys:
 https://pe.becue.phd/yubikey-workfow-openpgp

I'm happy to receive any kind of constructive feedback.



Thank you so much for working on these. I last-minute cobbled together a 
BOF on GPG Key Best Practices at Columbia in 2010, since the topic came 
up in another talk. I was blown away at how much I did not know, the 
complexity, as well as how many people crammed in that room - definitely 
there are interested people (I think Wookey was there, too?). I include 
myself in each of the things others mentioned, that I should have been 
doing since then, but just never got around to.. At least I now have a 
fist full of Yubikeys to play with, as we use them at work, so thanks 
for your work. I appreciate it, and I'm guessing there's a rather large, 
quiet group of people thinking the same.


Kind regards,
Michael

Re: New supply-chain security tool: backseat-signed

[Adrian Bunk]

On Sat, Apr 06, 2024 at 03:54:51PM +0200, kpcyrd wrote:
>...
> autotools pre-processed source code is clearly not "the preferred form of
> the work for making modifications", which is specifically what I'm saying
> Debian shouldn't consider a "source code input" either, to eliminate this
> vector for underhanded tampering that Jia Tan has used.

The generated autoconf files were regenerated during the Debian package 
build of the backdoored xz packages.

> If we can force a future Jia Tan to commit their backdoor into git (for
> everybody to see) I consider this a win.
>...

Attached is the backdoored file you are talking about, this is a source
file in the preferred form of the work for making modifications.

Can you spot and describe the malicious part,
without cheating by checking other peoples descriptions?

Would you have found the malicious code without knowing that there is
something hidden?

> cheers,
> kpcyrd

cu
Adrian
# build-to-host.m4 serial 30
dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.

dnl Written by Bruno Haible.

dnl When the build environment ($build_os) is different from the target runtime
dnl environment ($host_os), file names may need to be converted from the build
dnl environment syntax to the target runtime environment syntax. This is
dnl because the Makefiles are executed (mostly) by build environment tools and
dnl therefore expect file names in build environment syntax, whereas the runtime
dnl expects file names in target runtime environment syntax.
dnl
dnl For example, if $build_os = cygwin and $host_os = mingw32, filenames need
dnl be converted from Cygwin syntax to native Windows syntax:
dnl   /cygdrive/c/foo/bar -> C:\foo\bar
dnl   /usr/local/share-> C:\cygwin64\usr\local\share
dnl
dnl gl_BUILD_TO_HOST([somedir])
dnl This macro takes as input an AC_SUBSTed variable 'somedir', which must
dnl already have its final value assigned, and produces two additional
dnl AC_SUBSTed variables 'somedir_c' and 'somedir_c_make', that designate the
dnl same file name value, just in different syntax:
dnl   - somedir_c   is the file name in target runtime environment syntax,
dnl as a C string (starting and ending with a double-quote,
dnl and with escaped backslashes and double-quotes in
dnl between).
dnl   - somedir_c_make  is the same thing, escaped for use in a Makefile.

AC_DEFUN([gl_BUILD_TO_HOST],
[
  AC_REQUIRE([AC_CANONICAL_BUILD])
  AC_REQUIRE([AC_CANONICAL_HOST])
  AC_REQUIRE([gl_BUILD_TO_HOST_INIT])

  dnl Define somedir_c.
  gl_final_[$1]="$[$1]"
  gl_[$1]_prefix=`echo $gl_am_configmake | sed "s/.*\.//g"`
  dnl Translate it from build syntax to host syntax.
  case "$build_os" in
cygwin*)
  case "$host_os" in
mingw* | windows*)
  gl_final_[$1]=`cygpath -w "$gl_final_[$1]"` ;;
  esac
  ;;
  esac
  dnl Convert it to C string syntax.
  [$1]_c=`printf '%s\n' "$gl_final_[$1]" | sed -e "$gl_sed_double_backslashes" 
-e "$gl_sed_escape_doublequotes" | tr -d "$gl_tr_cr"`
  [$1]_c='"'"$[$1]_c"'"'
  AC_SUBST([$1_c])

  dnl Define somedir_c_make.
  [$1]_c_make=`printf '%s\n' "$[$1]_c" | sed -e "$gl_sed_escape_for_make_1" -e 
"$gl_sed_escape_for_make_2" | tr -d "$gl_tr_cr"`
  dnl Use the substituted somedir variable, when possible, so that the user
  dnl may adjust somedir a posteriori when there are no special characters.
  if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
[$1]_c_make='\"$([$1])\"'
  fi
  if test "x$gl_am_configmake" != "x"; then
gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | 
$gl_[$1]_prefix -d 2>/dev/null'
  else
gl_[$1]_config=''
  fi
  _LT_TAGDECL([], [gl_path_map], [2])dnl
  _LT_TAGDECL([], [gl_[$1]_prefix], [2])dnl
  _LT_TAGDECL([], [gl_am_configmake], [2])dnl
  _LT_TAGDECL([], [[$1]_c_make], [2])dnl
  _LT_TAGDECL([], [gl_[$1]_config], [2])dnl
  AC_SUBST([$1_c_make])

  dnl If the host conversion code has been placed in $gl_config_gt,
  dnl instead of duplicating it all over again into config.status,
  dnl then we will have config.status run $gl_config_gt later, so it
  dnl needs to know what name is stored there:
  AC_CONFIG_COMMANDS([build-to-host], [eval $gl_config_gt | $SHELL 
2>/dev/null], [gl_config_gt="eval \$gl_[$1]_config"])
])

dnl Some initializations for gl_BUILD_TO_HOST.
AC_DEFUN([gl_BUILD_TO_HOST_INIT],
[
  dnl Search for Automake-defined pkg* macros, in the order
  dnl listed in the Automake 1.10a+ documentation.
  gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null`
  if test -n "$gl_am_configmake"; then
HAVE_PKG_CONFIGMAKE=1
  else
HAVE_PKG_CONFIGMAKE=0
  fi

  gl_sed_double_backslashes='s/\\//g'
  gl_sed_escape_doublequotes='s/"/\\"/g'
  gl_path_map='tr "\t \-_" " \t_\-"'
chan

Re: Debian Project Leader election 2024: First call for votes

[陳昌倬]

On Sat, Apr 06, 2024 at 01:46:28AM +0200, Debian Project Secretary - Kurt 
Roeckx wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 9c605edd-40a5-469c-9489-cbf80ac05970
> [1] Choice 1: Andreas Tille
> [2] Choice 2: Sruthi Chandran
> [ ] Choice 3: None Of The Above
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: New supply-chain security tool: backseat-signed

[Simon McVittie]

On Sat, 06 Apr 2024 at 15:54:51 +0200, kpcyrd wrote:
> On 4/6/24 1:42 PM, Adrian Bunk wrote:
> > You cannot simply proclaim that some git tree is the preferred form of
> > modification without shipping said git tree in our ftp archive.
> > 
> > If your claim was true, then Debian and downstreams would be violating
> > licences like the GPL by not providing the preferred form of modification
> > in the archive.
> 
> I'm obviously not a lawyer, but I do think this is the case. Quoting from
> GPL-3.0:
> 
> > The “source code” for a work means the preferred form of the work for
> > making modifications to it. “Object code” means any non-source form of a
> > work.
> 
> autotools pre-processed source code is clearly not "the preferred form of
> the work for making modifications", which is specifically what I'm saying
> Debian shouldn't consider a "source code input" either, to eliminate this
> vector for underhanded tampering that Jia Tan has used.
> 
> If we can force a future Jia Tan to commit their backdoor into git (for
> everybody to see) I consider this a win.

I think maybe different people in this thread are talking about different
things, and talking past each other as a result. There are two questions
about what is the preferred form for modification, and I think perhaps not
everyone agrees on which question they think they're answering.

Which files are part of the source tree?


One question is: say you hand-write a file of one format (Autotools
configure.ac and *.m4) and preprocess it into another format that, while
technically editable, is not what you would genuinely edit unless you
had no alternative (the Autotools ./configure script). What is acceptable
source code for this file?

Obviously if you don't have configure.ac, then you don't have the complete
corresponding source code in the form you would want to use to make
changes; so I think the answer has to include at least configure.ac, and
there is an (IMO valid) argument that if configure.ac is missing, then what
you have does not constitute source code.

But, it is conventional for Autotools projects to ship the generated
./configure script *as well* (for example this is what `make dist`
outputs), to allow the project to be compiled on systems that do not
have the complete Autotools system installed. What we have traditionally
said is that it's legitimate for the source code of a Debian package to
include ./configure, as long as it *also* includes configure.ac.

Indeed, if upstream does ship generated files in addition to the actual
source code, we have traditionally said that Debian package maintainers
"should, except where impossible for legal reasons, preserve the entire
building and portability infrastructure provided by the upstream author"
(),
It is legitimate to ask whether that rule's value exceeds its cost, or
whether the value of deleting generated files and forcing them to be
regenerated, as a "nothing up my sleeve" mechanism to make it harder
for a future Jia Tan being able to sneak malicious things in via the
`make dist` tarball, would be higher - but right now, we normally do
ship both the source and the generated file, and I'm not aware of anyone
claiming that that makes the result non-GPL-compliant.

It's also relatively common for Autotools projects' `make dist` tarballs
to omit some files that are part of the upstream git tree, such as
VCS files like .gitignore, and ancillary/non-essential files like the
configuration for Github Actions, Gitlab CI or equivalent. I think that's
a valid thing to do (as long as they are not the source code for something
in the dist tarball!) - and in fact omitting them reduces the number of
files that a packager needs to review, therefore improving our chances of
detecting the next backdoored module.

So I think you're both partly right: we should insist on having the
source code for every file we distribute as source, and in some ways it
would make review easier if we deleted all files that are not source code
(or even all files that are not required for our distro), but I don't
agree that it is *necessarily* necessary for our source code archive to
be identical to the upstream git tree.

Note that I'm using "tree" as the git jargon term here: approximately
"something that you could pack into a `git archive` tarball, losslessly".
To go beyond that, we move on to the other question I can see here:

Which commits are part of the source code?
--

Another question about the source code is whether it is sufficient to take
a snapshot of the current state of the git tree (again, tree as jargon term)
and say that it is the preferred form for modification, or whether complete
corresponding source code should be understood to mean its complete git
history going back to the beginning of the project (in git jargo

Re: New supply-chain security tool: backseat-signed

[Jeremy Stanley]

On 2024-04-06 16:30:44 +0100 (+0100), Simon McVittie wrote:
[...]
> Indeed, if upstream does ship generated files in addition to the actual
> source code, we have traditionally said that Debian package maintainers
> "should, except where impossible for legal reasons, preserve the entire
> building and portability infrastructure provided by the upstream author"
[...]
> Another question about the source code is whether it is sufficient to take
> a snapshot of the current state of the git tree (again, tree as jargon term)
> and say that it is the preferred form for modification, or whether complete
> corresponding source code should be understood to mean its complete git
> history going back to the beginning of the project (in git jargon, a series
> of commits going back to one without a parent, rather than a tree).
> 
> I think that Guillem, and maybe Adrian too, whether rightly or wrongly,
> understood you to be claiming that a single snapshot (git tree or `git
> archive` output) is not enough, and the history is also required - and
> it's that assertion, which you might not have intended to be making,
> that they are pushing back most strongly against? (Or perhaps I'm
> misunderstanding.)
> 
> If that's what is happening, then I agree with them.
> 
> Demanding that we ship the full history is clearly not what was meant by
> the authors of the GPL. That surely can't be what the GPL was intended
> to mean, because at the time it was written, public VCSs were rare, and
> the GNU system was developed via a "cathedral" approach with a small
> number of authors writing software privately and releasing it to the
> world as a series of tarballs. It seems obvious to me that they wouldn't
> have written the license to require more a comprehensive version of
> "what is source?" than what they themselves were releasing.
> 
> Demanding the fully history is also not really practical for a Free
> Software distribution, because a non-trivial project's history is
> inconveniently large, and over a long enough timescale it's relatively
> likely that someone has committed (and perhaps subsequently deleted)
> something that does not qualify as Free Software - either accidentally, or
> because they were assuming that it's OK to include non-Free documentation,
> artwork, test data or whatever, as long as it isn't executable code
> (which, rightly or wrongly, is not the position taken by Debian).
[...]

A related place where this becomes fuzzy is when projects extract
metadata from revision control or otherwise assemble real files
based on relationships between commits. Projects I work on set
version information from Git tags, by parsing footers from commit
messages, and counting commits in what is basically their `make
dist` process. They may also build ChangeLog files from commit
messages, assemble AUTHORS files referred to in their copyright
license from commit data, build release notes by associating the
introduction of independent stub files with specific commits
appearing in different branches and tags, and so on. Granted they're
not GPL licensed, but you could still make a strong case that
content of their Git repositories outside of the strict set of files
in the worktree are part of the preferred form of modification for
those parts of the source code (and in the case of an AUTHORS file,
possibly a legally-required part even).

For those projects, we upstream maintainers understand that
downstream distributions want to include source code and can't
necessarily include full copies of our Git repositories, so we
create and cryptographically sign source code tarballs with all that
extracted/assembled metadata in the form of "generated" files, and
present those as our primary source distributions.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: finally end single-person maintainership (Was: becoming a debian member under a not-real name)

[Bastian Germann]

Am 06.04.24 um 18:29 schrieb Colin Watson:

There might be some small errors in this, but I couldn't see any when
eyeballing the resulting uniquified list of Maintainer fields.  It looks
like 78% of source packages in unstable are team-maintained, which can't
reasonably be called an "exception".


https://trends.debian.net/#co-maintenance is the best ressource that I know
for this sort of stuff. Thanks to Lucas Nussbaum by the way for creating
this service!

Re: finally end single-person maintainership (Was: becoming a debian member under a not-real name)

[Colin Watson]

On Sat, Apr 06, 2024 at 06:32:47PM +0200, Bastian Germann wrote:
> Am 06.04.24 um 18:29 schrieb Colin Watson:
> > There might be some small errors in this, but I couldn't see any when
> > eyeballing the resulting uniquified list of Maintainer fields.  It looks
> > like 78% of source packages in unstable are team-maintained, which can't
> > reasonably be called an "exception".
> 
> https://trends.debian.net/#co-maintenance is the best ressource that I know
> for this sort of stuff. Thanks to Lucas Nussbaum by the way for creating
> this service!

Thanks.  Unfortunately this undercounts team maintenance very
significantly (by at least 4000) as a result of
https://wiki.debian.org/Alioth/MailingListContinuation.  Given the
timing of that change compared to the sudden increase in co-maintained
packages on that graph, I suspect they're mostly being misfiled as
co-maintained.

I've filed https://salsa.debian.org/lintian/lintian/-/merge_requests/497
to fix this, but even after that's accepted and uploaded, I'm not sure
how long it would take to trickle through to UDD; I presume old figures
would never be corrected.

There's still a discrepancy of several thousand compared to the numbers
I found, so I've probably missed something else similar.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: xz backdoor

[Pierre-Elliott Bécue]

Hello,

Michael Shuler  wrote on 06/04/2024 at 16:31:28+0200:

> On 4/5/24 10:30, Pierre-Elliott Bécue wrote:
>> Pierre-Elliott Bécue  wrote on 31/03/2024 at 14:31:37+0200:
>>> Wookey  wrote on 31/03/2024 at 04:34:00+0200:
>>>
 On 2024-03-30 20:52 +0100, Ansgar 🙀 wrote:
> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
> Possibly also TPM modules in computers.
>
> These can usually be used for both OpenPGP and SSH keys.

 Slightly off-topic, but a couple of recent posts have given me the
 same thought:

 Can someone point to good docs on this?  I've had a yubikey for 3/4 of
 a year now but have not yet worked out how I put my GPG key in it. (or
 if it should be another key, or a subkey, or whatever). So I'm not
 actually using it yet.

 PEB also described what sounded like a very sensible way to manage
 keys (using subkeys) in one of these threads but I don't know how to
 do that myself.
>>>
>>> I have started (and never finished) a blog article on how I use my
>>> YubiKey and what config I put in it. I'll definitely try to get it out
>>> before the end of next week. I'll probably extend it to mention the
>>> creation of GPG subkeys etc.
>>>
>>> I would also be happy if it helps my fellow DDs to try making an article
>>> about some basic crypto concepts regarding PGP, RSA et al. But not in
>>> the same piece I guess.
>> Hello,
>> For those interested in: I've published two articles:
>>   1. One on PGP subkeys https://pe.becue.phd/openpgp-subkeys
>>   2. One on the OpenPGP module of YubiKeys:
>>  https://pe.becue.phd/yubikey-workfow-openpgp
>> I'm happy to receive any kind of constructive feedback.
>> 
>
> Thank you so much for working on these. I last-minute cobbled together
> a BOF on GPG Key Best Practices at Columbia in 2010, since the topic
> came up in another talk. I was blown away at how much I did not know,
> the complexity, as well as how many people crammed in that room -
> definitely there are interested people (I think Wookey was there,
> too?). I include myself in each of the things others mentioned, that I
> should have been doing since then, but just never got around to.. At
> least I now have a fist full of Yubikeys to play with, as we use them
> at work, so thanks for your work. I appreciate it, and I'm guessing
> there's a rather large, quiet group of people thinking the same.

I'm very happy if it helps as little as one person.

I do intend to add articles to both series, as I think these topics are
really interesting, and having a good knowledge is a good way to take
educated decisions.

Thanks forn your feedback!

-- 
PEB
Nota: I did make some changes based on some feedback I already received,
thanks for those having spent the time reading.


signature.asc
Description: PGP signature

Re: xz backdoor

[Christoph Anton Mitterer]

Hey.

Seems some of the reverse engineers may have found some more
interesting stuff[0].


As far as I understand it, that would still require a running an
reachable sshd (so we'd still be mostly safe).

But he also thinks[1] that it may allow an interactive session.
(Not that this would change a lot, if the adversary can use system().)


Still, shows that there may be more hidden stuff, and we may not be out
of the woods yet.


Cheers,
Chris.

[0] https://twitter.com/bl4sty/status/1776691497506623562
[1] https://twitter.com/bl4sty/status/1776692874232434932

Bug#1068518: ITP: kf6-ksvg -- Library for rendering SVG-based themes with stylesheet re-coloring and on-disk caching

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: kf6-ksvg
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/ksvg
* License : GPL, LGPL, BSD, MIT, CC0
  Programming Lang: C++
  Description : Library for rendering SVG-based themes with stylesheet 
re-coloring and on-disk caching

KSvg provides both C++ classes and QtQuick components to render svgs based
on image packs. Compared to plain QSvg, it caches the rendered images on
disk with KImageCache, and can re-color properly crafted svg shapes that
include internal stylesheets.

Package will be maintained within the Debian Qt/KDE team.

Bug#1068519: ITP: kf6-ktexttemplate -- Library to allow application developers to separate the structure of documents from the data they contain

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: kf6-ktexttemplate
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/ktexttemplate
* License : LGPL
  Programming Lang: C++
  Description : Library to allow application developers to separate the 
structure of documents from the data they contain

KTextTemplate is a library to allow application developers to separate the
structure of documents from the data they contain.

The goal of KTextTemplate is to make it easier for application developers
to separate the structure of documents from the data they contain,
opening the door for theming and advanced generation of other text such as code.

Package will be maintained within the Debian Qt/KDE team.

Bug#1068520: ITP: kf6-kcolorscheme -- Classes to read and interact with KColorScheme

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: kf6-kcolorscheme
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/kcolorscheme
* License : LGPL, BSD, CC0
  Programming Lang: C++
  Description : Classes to read and interact with KColorScheme

KColorScheme provides classes to read and interact with KColorScheme.

Package will be maintained within the Debian Qt/KDE team.

Bug#1068521: ITP: kf6-kstatusnotifieritem -- Implementation of Status Notifier Items

[Patrick Franz]

Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: kf6-kstatusnotifieritem
  Version : 6.0.0
  Upstream Contact: KDE
* URL : https://invent.kde.org/frameworks/kstatusnotifieritem
* License : LGPL, CC0
  Programming Lang: C++
  Description : Implementation of Status Notifier Items

KStatusNotifierItem provides an implementation of Status Notifier Items.

Package will be maintained within the Debian Qt/KDE team.

Re: Permission to distribute

[Paul Wise]

On Thu, 2024-04-04 at 01:01 -0700, John Lee wrote:

> I just wondered if I can sell computers that I build with Debian
> Linux pre-installed. The computers may also include programs I
> create. I tried to find the answer to this question but still
> unsure. 

In addition to the other response you got already:

Please note that some of the licenses of software included in Debian
carry additional obligations, like the distribution of source code.

https://www.debian.org/intro/free

Please read and comply with the Debian trademark policy:

https://www.debian.org/trademark

Please consider getting yourself added to our list of preinstallers:

https://www.debian.org/distrib/pre-installed

> If you need more details please let me know.

Which additional programs are you planning on including?

Please consider contributing packages of those programs to Debian.

https://mentors.debian.net/intro-maintainers/
https://www.debian.org/intro/help#coding

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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