gzip --rsyncable (was: Re: De-vendoring gnulib in Debian packages)

[Simon Josefsson]

"Theodore Ts'o"  writes:

> On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote:
>> Going into detail, you use 'gzip -9n' but I use git-archive defaults
>> which is the same as -n aka --no-name.  I agree adding -9 aka --best is
>> an improvement.  Gnulib's maint.mk also add --rsyncable, would you agree
>> that this is also an improvement?
>
> I'm not convinced --rsyncable is an improvement.  It makes the
> compressed object slightly larger, and in exchange, if the compressed
> object changes slightly, it's possible that when you rsync the changed
> file, it might be more efficient.  But in the case of PGP signed
> release tarballs, the file is constant; it's never going to change,
> and even if there are slight changes between say, e2fsprogs v1.47.0
> and e2fsprogs v1.47.1, in practice, this is not something --rsyncable
> can take advantage of, unless you manually copy
> e2fsprogs-v1.47.0.tar.gz to e2fsprogs-v1.47.1.tar.bz, and then rsync
> e2fsprogs-v1.471.tar.g and I don't think anyone is doing this,
> either automatically or manually.
>
> That being said, --rsyncable is mostly harmless, so I don't have
> strong feelings about changing it to add or remove in someone's
> release workflow.

Your example had me convinced, and I thought some more about why we
really should keep using it as it consumes a small percentage more CPU
and disk space.  I have realized that another common operation is
storing and transfering _several_ different releases of e2fsprogs.  I
would suspect that most releases of software is fairly similar to the
previous release when uncompressed.  With gzip --rsyncable, the tarballs
should then be mostly similar.  Without --rsyncable, they will largely
be different if I understand correctly.  This affects dedup-able storage
and transfer methods, and some anecdotical evidence suggests this
improvement is significant - going from 215GB to 176GB vs 13GB:

https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/429

Maybe someone could do some experiment to see if there is substance to
this argument, its not clear to me that the example is comparable.
Storing/transferring several releases for the same software could add
significant savings for larger set of archives.

As the downside seems fairly small, and the potential upside may be
significant, I will use and recommend --rsyncable for git-archive
release tarballs:

   git archive --format=tar --prefix=$PACKAGE-$VERSION/ HEAD | \
  env GZIP= gzip --no-name --best --rsyncable \
  > $PACKAGE-$VERSION-src.tar.gz

/Simon


signature.asc
Description: PGP signature

Re: De-vendoring gnulib in Debian packages

[Simon Josefsson]

"Theodore Ts'o"  writes:

>> 1) Use upstream's PGP signed git-archive tarball.
>
> Here's how I do it in e2fsprogs which (a) makes the git-archive
> tarball be bit-for-bit reproducible given a particular git commit ID,
> and (b) minimizes the size of the tarball when stored using
> pristine-tar:
>
> https://github.com/tytso/e2fsprogs/blob/master/util/gen-git-tarball

Wow, written five years ago and basically the same thing that I suggest
(although you store pre-generated ./configure scripts in git).

Going into detail, you use 'gzip -9n' but I use git-archive defaults
which is the same as -n aka --no-name.  I agree adding -9 aka --best is
an improvement.  Gnulib's maint.mk also add --rsyncable, would you agree
that this is also an improvement?  Thus what I'm arriving at is this:

git archive --prefix=inetutils-$(git describe)/ HEAD |
   gzip --no-name --best --rsyncable > -o inetutils-$(git describe)-src.tar.gz

>> To reach our goals in the beginning of this post, this upstream tarball
>> has to be filtered to remove all pre-generated artifacts and vendored
>> code.  Use some mechanism, like the debian/copyright Files-Excluded
>> mechanism to remove them.  If you used a git-archive upstream tarball,
>> chances are higher that you won't have to do a lot of work especially
>> for pre-generated scripts.
>
> Why does it *has* to be filtered?  For the purposes of building, if
> you really want to nuke all of the pre-generated files, you can just
> move them out of the way at the beginning of the debian/rules run, and
> then move them back as part of "debian/rules clean".  Then you can use
> autoreconf -fi to your heart's content in debian/rules (modulo
> possibly breaking things if you insist on nuking aclocal.m4 and
> regenerating it without taking proper care, as discussed above).
>
> This also allows the *.orig.tar.gz to be the same as the upstream
> signed PGP tarball, which you've said is the ideal, no?

Right, there is no requirement for orig.tar.gz to be filtered.  But then
the outcome depends on upstream, and I don't think we can convince all
upstreams about these concerns.  Most upstream prefer to ship
pre-generated and vendored files in their tarballs, and will continue to
do so.  Let's assume upstream doesn't ship minimized tarballs that are
free from vendored or pre-generated files.  That's the case for most
upstream tarballs in Debian today (including e2fsprogs, openssh,
coreutils).  Without filtering that tarball we won't fulfil the goals I
mentioned in the beginning of my post.  The downsides with not filtering
include (somewhat repeating myself):

- Opens up for bugs causing pre-generated files not being re-generated
  even when they are used to build the package.  I think this is fairly
  common in Debian packages.  Making sure all pre-generated files are
  re-generated during build -- or confirming that the file is not used
  at all -- is tedious and fragile work.  Work that has to be done for
  every release.  Are you certain that ./configure is re-generated?  If
  it is not present you would notice.

- Auditing the pre-generated and vendored files for malicious content
  takes more time than not having to audit those files.  Especially if
  those files are not stored in upstream git.

- Pre-generated and vendored files trigger licensing concerns and
  require tedious work that doesn't improve the binary package
  deliverable.  Consider files like texinfo.tex for example, wouldn't it
  be better to strip that out of tarballs and not have to add it to
  debian/copyright?  If some code in a package, let's say getopt.c, is
  not used during build of the package, the license of that file doesn't
  have to be mentioned in debian/copyright if I understand correctly:
  https://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright
  If in a few releases later, that file starts to get used during
  compilation, the package maintainer will likely not notice.  If it was
  filtered, the maintainer would notice.

The best is when upstream ship a tarball consistent with what I dream
*.orig.tar.gz should be: free of vendored and pre-generated files.
Debian package maintainers can take action before this happens, to reach
nice properties within Debian.  Maybe some upstream will adapt.

>> There is one design of gnulib that is important to understand: gnulib is
>> a source-only library and is not versioned and has no release tarballs.
>> Its release artifact is the git repository containing all the commits.
>> Packages like coreutils, gzip, tar etc pin to one particular commit of
>> gnulib.
>
> Note that how we treat gnulib is a bit differently from how we treat
> other C shared libraries, where we claim that *all* libraries must be
> dynamically linked, and that include source code by reference is
> against Debian Policy, precisely because of the toil needed to update
> all of the binary packages should some security vulnerability gets
> discovered in the library which is either linked statically 

Re: De-vendoring gnulib in Debian packages

[Simon Josefsson]

Bruno Haible  writes:

> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
>   * 'npm install' for JavaScript source code packages [1],
>   * 'cargo fetch' for Rust source code packages [2],
>
> except that gnulib-tool is simpler: it fetches from a single source location
> only.
>
> How does Debian handle these kinds of source-code dependencies?

I don't know the details but I believe those commands are turned into
local requests for source code, either vendored or previously packaged
in Debian.  No network access during builds.  Same for Go packages,
which I have some experience with, although for Go packages they lose
the strict versioning so if Go package X declare a depedency on package
Y version Z then on Debian it may build against version Z+1 or Z+2 which
may in theory break and was not upstream's intended or supported
configuration.  We have a circular dependency situation for some core Go
libraries in Debian right now due to this.

I think fundamentally the shift that causes challenges for distributions
may be dealing with packages dependencies that are version >= X to
package dependencies that are version = X.  If there is a desire to
support that, some new patterns of the work flow is needed.  Some
package maintainers reject this approach and refuse to co-operate with
those upstreams, but I'm not sure if this is a long-term winning
strategy: it often just lead to useful projects not being available
through distributions, and users suffers as a result.

/Simon


signature.asc
Description: PGP signature

De-vendoring gnulib in Debian packages

[Simon Josefsson]

e and sign it yourself.  Could be done something like this:

   git clone https://git.savannah.gnu.org/git/inetutils.git
   cd inetutils/
   git archive --prefix=inetutils-v2.5/ -o inetutils-2.5-src.tar.gz v2.5
   # additional filtering of tarball may go here
   gpg -b inetutils-2.5-src.tar.gz

   This is your new upstream tarball.  To build this particular one, use
   ./bootstrap --no-git --gnulib-srcdir=/usr/share/gnulib.

4) Use upstream's git-archive tarball and PGP sign it.

   Download it using the GitHub or GitLab download link on the git tag
   like the cool kids.  If you did this on a sunny day, the downloaded
   tarball should be identical to the git-archive tarball and you can
   sign it if you are comfortable with this.

5) Use upstream's git-archive tarball.

   For those who want to join the really cool kids club.

6) Use upstream's tarball without PGP signature.

   This is quite common today.  It happens when upstream doesn't publish
   PGP signatures or the Debian maintainer doesn't care about them.

Regardless of mechanism, you should end up with a tarball that we call
the "upstream tarball".  Which approach is chosen is subjective and up
to the Debian package maintainer.  people have different opinions.
While I can't hide my own preferences I think we have to acknowledge
that there is no single uniform answer here.

To reach our goals in the beginning of this post, this upstream tarball
has to be filtered to remove all pre-generated artifacts and vendored
code.  Use some mechanism, like the debian/copyright Files-Excluded
mechanism to remove them.  If you used a git-archive upstream tarball,
chances are higher that you won't have to do a lot of work especially
for pre-generated scripts.

This filtered tarball will be the *.orig.tar.gz used to build the Debian
package.

Ideally you would like for the *.orig.tar.gz tarball to be as close as
possible to upstream's git repository for the tag release, minus any
pre-generated scripts or vendored gnulib files that upstream put into
git.  For collaborative upstreams, you could try to convince them to not
put pre-generated scripts and vendored gnulib files into git.

Auditing the upstream tarball to the *.orig.tar.gz should be simple, use
sha256sum or diffoscope to compare content.  In some ideal world this
could be bit-by-bit identical.  I'm hoping this can be the new best
recommended approach going forward.  This is only possible when upstream
agree with these concerns, and make an effort to publish such minimized
source-only tarballs.  This may be a pipe dream, just like Debian's
current best recommended approach for upstream PGP signed tarballs are
sometimes ignored.

You will now be faced with the challenge of building this tarball.  Your
existing debian/rules makefile will not work any more since it assumed
the existance of the pre-generated scripts and vendored gnulib files.
So you have to add the required tools as Build-Depends: and update the
debian/rules to build everything from source code.

For libntlm the essential diff between version 1.7-1, that used upstream
tarball with pre-generated content and gnulib code, and latest version
1.8-3 that builds from a minimal source-only tarball is small:

--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Uploaders:
  Simon Josefsson ,
 Build-Depends:
  debhelper-compat (= 13),
+ git,
+ gnulib (>= 20240412~dfb7117+stable202401.20240408~aa0aa87-3~),
 Standards-Version: 4.6.2
 Section: libs
 Homepage: https://www.nongnu.org/libntlm/
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,16 @@
 #! /usr/bin/make -f
 
+include /usr/share/gnulib/debian/gnulib-dpkg.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-   dh $@ --builddirectory=build -X.la
+   dh $@ --without autoreconf --builddirectory=build
+
+pull:
+   ./bootstrap --gnulib-srcdir=$(GNULIB_DEB_DEBIAN_GNULIB) --pull
+
+gen:
+   ./bootstrap --gnulib-srcdir=$(GNULIB_DEB_DEBIAN_GNULIB) --gen
+
+execute_before_dh_auto_configure: dh_gnulib_clone pull dh_gnulib_patch gen

As you can see the essential part is to add a Build-Depends on the
gnulib Debian package to get the necessary gnulib code for building.  We
also disable dh_autoreconf since its approach is no longer necessary
(and hides problems), everything is built from source coming from Debian
or upstream.

There is one design of gnulib that is important to understand: gnulib is
a source-only library and is not versioned and has no release tarballs.
Its release artifact is the git repository containing all the commits.
Packages like coreutils, gzip, tar etc pin to one particular commit of
gnulib.  There is little coordination among packages which gnulib git
commit to use, and historically they typically use the latest gnulib git
commit that was published when the release manager prepared a release.
Usually the pinning happens through a git submodule or through the
GNULIB_REVISION bootstrap.conf mechanisms, but there is no requirement
from gnuli

archive.debian.org mirrors

[Simon Josefsson]

Hi

According to the mirror list

https://www.debian.org/distrib/archive

it should be possible to reach archive.debian.org via rsync, however
this fails for me.  Is this intentional, or can this be fixed?

Further it seems mirrors are out of sync.  I noticed that several
mirrors lack buster.  According to timestamps on archive.debian.org
these directories were added on 2024-03-10 -- is it usual for mirror
delays to be this long?

Seeing mirror functionality being uncertain, I have started to track
archive.debian.org as a Git-LFS repository on gitlab.com.  Until rsync
access against archive.debian.org is operational, this is based on
mirror's content which may be stale. I hope to figure out which rsync
mirror has the latest version, and keep this updated going forward.

https://gitlab.com/debdistutils/archives/debian/archive.debian.org

/Simon


signature.asc
Description: PGP signature

Re: Binary conflict between Midnight Commander and MinIO Client

[Simon Josefsson]

Philip Hands  writes:

> Mathias Gibbens  writes:
>
>> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> ...
>>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives in /usr/bin?  That way the existence of the lib directory is
> somewhat self-documenting.
>
> If you're looking for examples, it seems that fd-find and binutils-avr
> do something like this (although they seem to be linking into ../lib/
> presumably for historical reasons).

It seems this approach could use some documentation, if we want to have
some consistent implementation of this idea in Debian.  While I usually
dislike symlinks in /usr/bin/ I think there is some advantages.  I'm
also not sure where a good path component to store such binaries are,
libexec or lib?  Or share?

/Simon


signature.asc
Description: PGP signature

Re: Binary conflict between Midnight Commander and MinIO Client

[Simon Josefsson]

Marco d'Itri  writes:

> On Apr 21, Mathias Gibbens  wrote:
>
>>   While that might work for them, it obviously doesn't at a higher
>> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
>> for any comments or suggestions on my plan for packaging the MinIO
>> Client. Following what several other distributions have done[2], I'm
>> planning to name the source/binary packages "minio-client" and the
>> binary provided from that package will be `mcli`.

+1

> Go for it, I think that there is no good solution for this case.
> Everybody who cares then will manually create a mc -> mcli symlink.

Several Homebrew packages uses an approach that I regard as superior to
what the debian ecosystem provides for this problem: putting files in a
path that users can add to their $PATH to get upstreams' desired binary
name, when there is a conflict with a historically established name.  So
for this example, minio-client could create a symlink like this

/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli

and users who really want the upstream behaviour can solve this by
modifying environment variables.

/Simon


signature.asc
Description: PGP signature

Re: gnulib

[Simon Josefsson]

Jonas Smedegaard  writes:

> Quoting Simon Josefsson (2024-04-18 09:34:26)
>> Jonas Smedegaard  writes:
>> 
>> > That said, you are welcome to try nudge me if some concrete task
>> > emerges where you image I might be of help.
>> 
>> Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to
>> allow others to help and to allow you from not having to feel a need to
>> reply at all :)
>
> Thanks for releaving me.
>
> ...but then you bring up licensing, which has my special interest :-D

I am terribly sorry :-)

>> One of the things that bothered me with the gnulib Debian package that
>> I've been too afraid to touch is the debian/copyright file.  It triggers
>> a lot of lintian errors:
>> 
>> https://udd.debian.org/lintian/?packages=gnulib
>> 
>> For reference here is current debian/copyright:
>> 
>> https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright
>> 
>> I've seen debian/clscan/ and ran the tools there, but I don't yet feel
>> comfortable patching things, and it didn't produce clean results even
>> for the last version in testing before I started to work on this
>> package, so I'm not convinced this toolchain is the best approach going
>> forward.
>
> When I took over maintenance my first thought was also to get rid of the
> clscan script, but then I realized how enormous a work it would be to
> approach it differently and wrapped my head around the script and
> adjusted it.
>
> Does it sound like you are in a similar situation now as I was, or is
> there something in particular that makes you consider abandoning
> clscan?

Yes you are right.  There is nothing in particular that I've found,
except that I don't understand how it is supposed to work and I felt
uncertain if it was worth wrapping my head around or not.

>> One problem is that lintian doesn't like [REF01] in lines like this:
>> 
>> License: FSFAP [REF01]
>
> I agree with lintian about the above (but we disagree on other things -
> see bug#786450). I am confident that the above syntax is incorrect:
> copyright format 1.0 requires a single-word shortname.

That is good to establish, and I wasn't even certain of that.  Then it
is clear that it is the gnulib debian/copyright file that should change.
And the discussion can move to what it should change into.

> If you are simply not fluent in perl, then perhaps reach out to the
> Debian perl team for help? Or perhaps look in the git history the tweaks
> that I made - perhaps those are of inspiration to whatever issue you are
> running into now?

I will try to do that -- and will experiment with it to see if I get an
improved copyright file out of it, maybe using a Comment: approach
instead of the invalid [REF01] approach.

/Simon


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Simon Josefsson]

Sebastian Ramacher  writes:

> Hi,
>
> as the progress on the t64 transition is slowing down, I want to give an
> overview of some of the remaining blockers that we need to tackle to get
> it unstuck. I tried to identify some clusters of issues, but there might
> be other classes of issues.

Thanks for update.  I haven't seen any response to my analysis of why
'shishi' shouldn't have t64-migrating, and lacking any response I
eventually made an upload to revert the renaming.  I've raised an Ubuntu
bug too since they haven't synced the updated package.  The Debian bug
is now closed, so it wasn't included in your list, and maybe everything
that can be hoped for is already achieved, but I wanted to mention as it
ought to be on the t64 radar.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062896
https://bugs.launchpad.net/ubuntu/+source/shishi/+bug/2061743
https://tracker.debian.org/pkg/shishi

/Simon


signature.asc
Description: PGP signature

Re: gnulib

[Simon Josefsson]

Jonas Smedegaard  writes:

> That said, you are welcome to try nudge me if some concrete task
> emerges where you image I might be of help.

Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to
allow others to help and to allow you from not having to feel a need to
reply at all :)

One of the things that bothered me with the gnulib Debian package that
I've been too afraid to touch is the debian/copyright file.  It triggers
a lot of lintian errors:

https://udd.debian.org/lintian/?packages=gnulib

For reference here is current debian/copyright:

https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright

I've seen debian/clscan/ and ran the tools there, but I don't yet feel
comfortable patching things, and it didn't produce clean results even
for the last version in testing before I started to work on this
package, so I'm not convinced this toolchain is the best approach going
forward.

One problem is that lintian doesn't like [REF01] in lines like this:

License: FSFAP [REF01]

Is the reason why this is done that you want to record a full copy of
the actual text from the particular file AND some more information?
Sometimes there is a file X with the FSFAP license and some additional
text not part of the core FSFAP license, and another file Y that also
uses FSFAP but has some OTHER additional text that you want to record?

In some other packages, I've used the Comment: field like this for
situations like that.  Maybe it is applicable here?

Files: *
Copyright: 2016 Google LLC. All Rights Reserved.
   2022 Trillian Authors. All Rights Reserved.
   2016 The Kubernetes Authors.
   2017 Google LLC. All Rights Reserved.
License: Apache-2.0
Comment: Quoting AUTHORS:
 # This is the official list of benchmark authors for copyright purposes.
 Antonio Marcedone 
 Google LLC
 Internet Security Research Group
 Vishal Kuo 

The idea is that from a legal perspective, the copyright notices and
keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is
sufficient documentation.  However, for reasons like proper attribution
and having more background information, it is useful to say something
more than what's legally required, including properly quoting the
relevant files.  I think the Comment: section makes for a better place
than License: fields for this.

Does anyone have other advice related to gnulib's debian/copyright file?

I have yet to fully get a grip on how this file should best reflect
reality for a complex package like gnulib, but will try to do my best to
resolve lintian complaints and keep it accurate and maintainable.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Colin Watson  writes:

> On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
>> Running ./bootstrap in a tarball may lead to different results than the
>> maintainer running ./bootstrap in pristine git.  It is the same problem
>> as running 'autoreconf -fvi' in a tarball does not necessarily lead to
>> the same result as the maintainer running 'autoreconf -fvi' from
>> pristine git.  The different is what is pulled in from the system
>> environment.  Neither tool was designed to be run from within a tarball,
>> so this is just bad practice that never worked reliable and without a
>> lot of complexity it will likely not become reliable either.
>
> The practice of running "autoreconf -fi" or similar via dh-autoreconf
> has worked extremely well at scale in Debian.  I'm sure there are
> complex edge cases where it's caused problems, but it's far from being a
> disaster area.

Agreed.  I'm saying it doesn't fix the problem that I perceive that some
people appear to believe, i.e., that running 'autoreconf -fi' solves the
re-bootrapping problem.  Only some files get re-generated, such as the
./configure script, which is good, but not all files.  It wouldn't have
solved the xz case: build-to-host.m4 wouldn't have been re-generated.

With a *-src.tar.gz approach [1], the build-to-host.m4 file shouldn't
even be part of the tarball.  That would be easier to detect during an
audit of list of files compared to git repository, rather than waiting
for code review of file content (which usually only happens when
debugging some real-world problem).

[1] 
https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/

> I don't think running ./bootstrap can be generalized as easily as
> running autoreconf can, and it's definitely going to be tough to apply
> to all packages that use gnulib; but I think the blanket statement that
> it's bad practice is painting with too broad a brush.  For the packages
> where I've applied it so far (most of which I'm upstream for,
> admittedly), it's fine.

I'm not saying autoreconf -fi is bad practice, I'm saying it is
incomplete and leads to a feeling of having solved the re-bootstrapping
problem that isn't backed by facts.

>> I have suggested before that upstream's (myself included) should publish
>> PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
>> checkout including submodules,
>
> A while back I contributed support to Gnulib's bootstrap script to allow
> pinning particular commits without using submodules.  I would recommend
> this mode; submodules have very strange UI.

I never liked git submodules generally, so I would be happy to work on
getting that to be supported -- do you have pointers for earlier works
here?

What is necessary, I think, is having something like this in
bootstrap.conf:

gnulib_commit_id = 123abc567...

and it would then use the external git repository pointed to by
--gnulib-refdir and locate that commit, and extract the gnulib files
from that gnulib commit.  And refuse to continue if it can't find that
particular commit.

This is essentially the same as a git submodule -- encoding the gnulib
commit to use in the project's own git history -- but without the bad
git submodule user experience.

I use different approaches to gnulib in projects. In OATH Toolkit I
still put all gnulib-generated content in git because running
./bootstrap otherwise used to take several minutes.  In most projects I
have given up and use git submodules.  In some I rely on running
gnulib-tool from git, and the exact gnulib git commit to use is only
whatever I happened to have checked out on my development machine.

>> *.po translations,
>
> As I noted in a comment on your blog, I think there is a case to be made
> for .po files being committed to upstream git, and I'm not fond of the
> practice of pulling them in only at bootstrap time (although I can
> understand why that's come to be popular as a result of limited
> maintainer time).  I have several reasons to believe this:

Those are all good arguments, but it still feels backwards to put these
files into git.  It felt so good to externalize all the translation
churn outside of my git (or then, CVS...) repositories many years ago.

I would prefer to maintain a po/SHA256SUMS in git and continue to
download translations but have some mechanism to refuse to continue if
the hashes differ.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

"G. Branden Robinson"  writes:

> At 2024-03-31T22:32:49+, Stefano Rivera wrote:
>> Upstreams would probably prefer that we used git repositories
>> *directly* as source artifacts, but that comes with a whole other can
>> of worms...
>
> Speaking from my upstream groff perspective, I wouldn't _prefer_ that.
>
> The distribution archives get build-testing on a much wider variety of
> systems, thanks to people on the groff@ and platform-testers@gnu mailing
> lists that help out when a release candidate is announced.  They have
> access to platforms more exotic that I and a few other bleeding-edge
> HEAD mavens do.  This practice tangibly improved the quality of the
> groff 1.23.0 release, especially on surviving proprietary Unix systems.
>
> Building from the repo, or using the bootstrap script--which Colin
> Watson just today ensured will be in future distribution archives--is
> fine.[1]  I'm glad some people build the project that way.  But I think
> that procedure serves an audience that is distinguishable in some ways.

Running ./bootstrap in a tarball may lead to different results than the
maintainer running ./bootstrap in pristine git.  It is the same problem
as running 'autoreconf -fvi' in a tarball does not necessarily lead to
the same result as the maintainer running 'autoreconf -fvi' from
pristine git.  The different is what is pulled in from the system
environment.  Neither tool was designed to be run from within a tarball,
so this is just bad practice that never worked reliable and without a
lot of complexity it will likely not become reliable either.

I have suggested before that upstream's (myself included) should publish
PGP-signed *-src.tar.gz tarballs that contain the entire pristine git
checkout including submodules, *.po translations, and whatever else is
required to actually build the project that is normally pulled in from
external places (autoconf archive macros?).  This *-src.tar.gz tarball
should be possible to ./bootstrap and that would be the intended way to
build it for people who care about vendored files.  Thoughts?  Perhaps I
should formalize this proposal a bit more.

/Simon

> Regards,
> Branden
>
> [1] 
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=822fef56e9ab7cbe69337b045f6f20e32e25f566
>


signature.asc
Description: PGP signature

Re: Git and SHA1 collisions

[Simon Josefsson]

Gioele Barabucci  writes:

> But pulling a successful collision attack is not a trivial task. For
> instance, the xz attacker did not have all that was required to carry
> it out (for example they had no direct access to the git
> servers... yet).

Is that necessary?  It seems that if you have push access, you can push
a colliding commit.  Does GitLab on Salsa verify (and reject?) colliding
commit ids a'la SHA1-CD?  Would the tag2upload git server do that?

/Simon


signature.asc
Description: PGP signature

Re: xz backdoor

[Simon Josefsson]

Bastian Blank  writes:

> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
>> > As others have said, the best solution is to relay on HSW for handling
>> > the cryptographic material.
>> Aren't these answers to different questions?
>> Not all attacks are about stealing the key or using it to sign unintended
>> things.
>
> Also a HSM does only allow to control access to the cryptographic
> material.  But it asserts no control over what is actually signed.

Transparency techniques are better suited to solve that problem: make
sure that you don't trust a signature before verifying that the
signature was publicly logged together with its artifacts, so that they
can be independently audited and analyzed eventually.  Preferrably even
verify that the package artifacts build reproducible, but that takes
more resources.  Right now Debian trust signatures at face value which
is fragile.  The WebPKI world -- which is populated by untrustworthy
private key signers -- has moved in that direction, and it does improve
things.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Russ Allbery  writes:

> Simon Josefsson  writes:
>> Sean Whitton  writes:
>
>>> We did some analysis on the SHA1 vulnerabilities and determined that
>>> they did not meaningfully affect dgit & tag2upload's design.
>
>> Can you share that analysis?  As far as I understand, it is possible for
>> a malicious actor to create a git repository with the same commit id as
>> HEAD, with different historic commits and tree content.  I thought a
>> signed tag is merely a signed reference to a particular commit id.  If
>> that commit id is a SHA1 reference, that opens up for ambiguity given
>> recent (well, 2019) results on SHA1.  Of course, I may be wrong in any
>> of the chain, so would appreciate explanation of how this doesn't work.
>
> I believe you're talking about two different things.  I think Sean is
> talking about preimage resistance, which assumes that the known-good
> repository is trusted, and I believe Simon is talking about manufactured
> collisions where the attacker controls both the good and the bad
> repository.

Right.  I think the latter describes the xz scenario: someone could have
pushed a maliciously crafted commit with a SHA1 collision commit id, so
there are two different git repositories with that commit id, and a
signed git tag on that commit id authenticates both trees, opening up
for uncertainty about what was intended to be used.  Unless I'm missing
some detail of how git signed tag verification works that would catch
this.

> The dgit and tag2upload design probably (I'd have to think about it some
> more, ideally while bouncing the problem off of someone else, because I've
> recycled those brain cells for other things) only needs preimage
> resistance, but the general case of a malicious upstream may be vulnerable
> to manufactured collisions.

It is not completely clear to me: How about if some malicious person
pushed a commit to salsa, asked a DD to "please review this repository
and sign a tag to make the upload"?  The DD would presumably sign a
commit id that authenticate two different git trees, one with the
exploit and one without it.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Jonathan Carter  writes:

> On 2024/03/30 11:05, Simon Josefsson wrote:
>>> 1. Move towards allowing, and then favoring, git-tags over source tarballs
>>
>> Some people have suggested this before -- and I have considered adopting
>> that approach myself, but one thing that is often overlooked is that
>> building from git usually increase the Build-Depends quite a lot
>> compared to building from tarball
>
> How in the world do you jump to that conclusion?

By comparing the set of tools required to build from git with the tools
installed by Build-Depends* for common projects.  I'm thinking of
projects like coreutils, wget, libidn2, gnutls, gzip, etc.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Sean Whitton  writes:

> Hello,
>
> On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote:
>
>> Relying on signed git tags is not reliable because git is primarily
>> SHA1-based which in 2019 cost $45K to do a collission attack for.
>
> We did some analysis on the SHA1 vulnerabilities and determined that
> they did not meaningfully affect dgit & tag2upload's design.

Can you share that analysis?  As far as I understand, it is possible for
a malicious actor to create a git repository with the same commit id as
HEAD, with different historic commits and tree content.  I thought a
signed tag is merely a signed reference to a particular commit id.  If
that commit id is a SHA1 reference, that opens up for ambiguity given
recent (well, 2019) results on SHA1.  Of course, I may be wrong in any
of the chain, so would appreciate explanation of how this doesn't work.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Gioele Barabucci  writes:

> Just as an example, bootstrapping coreutils currently requires
> bootstrapping at least 68 other packages, including libx11-6 [1]. If 
> coreutils supported  [2], the transitive closure of its
> Build-Depends would be reduced to 20 packages, most of which in 
> build-essential.
>
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=coreutils=amd64=9.4-3.1=1710441056=1
> [2] https://bugs.debian.org/1057136

Coreutils in Debian uses upstream tarballs and does not do a full
bootstrap build.  It does autoreconf instead of ./bootstrap.  So the
dependencies above is not the entire bootstrapping story to build
coreutils from git compared to building from tarballs.

It would help if upstreams would publish PGP-signed 'git-archive'-style
tarballs, including content from git submodules in them.

Relying on signed git tags is not reliable because git is primarily
SHA1-based which in 2019 cost $45K to do a collission attack for.

/Simon


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Simon Josefsson]

Antonio Russo  writes:

> 1. Move towards allowing, and then favoring, git-tags over source tarballs

Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends quite a lot
compared to building from tarball, and that will more likely trigger
cyclic dependencies.  People that do bootstrapping for new platforms or
cross-platform dislike such added dependency.

One response to that may be "sorry, our concerns for supply chain
security trumps your desire for easier building" but so far I believe
the approach has been to compromise a little on supply chain side (i.e.,
building from tarballs) and compromise a little on the
bootstrap/crossbuild smoothness (e.g., adding nodoc or nocheck targets).

Moving that needle isn't all that trivial, although I think I'm moving
myself to a preference that we really need to build everything from
source code and preferrably not even including non-source code files
because they may dormant and activated later on a'la the xz attack.

An old irk of mine is that people seems to believe that running
'autoreconf -fi' is intended or supposed to combat problems related to
this: autoreconf was never designed for that purpose, nor does it
achieve it realiably.  Many distributions have adopted a preference to
do run 'autoreconf' to "re-bootstrap" a project from source code.  This
misses a lot of generated files, and sometimes generate incorrect (and
possibly harmful) newly generated files.  For example:
https://gitlab.com/libidn/libidn2/-/issues/108

/Simon


signature.asc
Description: PGP signature

Re: Transparency into private keys of Debian

[Simon Josefsson]

Hans-Christoph Steiner  writes:

>> In business, such things are confirmed (often badly) by independent
>> audit. For a volunteer-driven community effort, we have to rely on
>> everyone to exercise their best judgement in these sorts of matters.
>
> Debian could also get independent, professional audits.  I think it
> would be a good use of the Debian pot of money, for example.  Or
> someone could submit a proposal to get Debian audited.  I'll be either
> Open Tech Fund or NLnet would do it:
>
> https://www.opentech.fund/labs/red-team-lab/
>
> Open Tech Fund already funds Tails, which is based on Debian.

That would be useful for the important keys like the apt release keys,
and would set an example for others to follow.  If there are things to
improve, it would be better if we know about them than allowing
attackers to find out on their own.  For DD keys, as Jemery noticed, I
don't think it is useful: uses of DD keys leave a quite auditable flow
already.

/Simon


signature.asc
Description: PGP signature

Re: Transparency into private keys of Debian

[Simon Josefsson]

> > I've looked at Sigstore, it looks nice.  It seems to be architected
> > for use 
> > cases that assume highly reliable and unblocked single domains. 
> > That's a 
> > showstopper for us.  Also, the official client app is 100% JVM code
> > right now 
> > (Java+Kotlin), so integrating Go binaries would really be an option
> > of last 
> > resort.  Its almost a no go for many reasons.
> 
> Agreed -- having a C, perl or python client for Sigstore or Sigsum
> would be nice.  I'll bring this up with them.

I should have checked before sending the previous email, there is this
client:

https://git.glasklar.is/sigsum/core/sigsum-py

I suppose for apt python is more relevant, and if the sigsum proof is
included alongside apt metadata, it would allow offline verification
inside apt.  If apt doesn't support this natively, the proof would have
to be distributed through some other channel, but that is relatively
easy to do as a Proof-of-Concept (i.e., how apt-sigstore +
debdistcanary already works via gitlab) but scaling it to decentralized
etc remains to be resolved, if relevant.

/Simon

> 
> /Simon
> 
> > 
> > Hans
> > 
> > > 
> > > /Simon
> > > 
> > > > And publishing the jurisdictions could be enough info to
> > > > deanonymize
> > > > the key holder, e.g. if it is Germany, then there are many DDs
> > > > there.
> > > > If it is Iceland, then govs can easily find who to target.
> > > > 
> > > > .hc
> > > > 
> > > > > Hi
> > > > > I'm exploring how to defend against an attacker who can
> > > > > create
> > > > > valid
> > > > > signatures for cryptographic private keys (e.g., PGP) that
> > > > > users need to
> > > > > trust when using an operating system such as Debian.  A
> > > > > signature like
> > > > > that can be used in a targetted attacks against one victim.
> > > > > For example, apt does not have any protection against this
> > > > > threat
> > > > > scenario, and often unprotected ftp:// or http:// transports
> > > > > are used,
> > > > > which are easy to man-in-the-middle.  Even with https://
> > > > > there
> > > > > is a
> > > > > large number of mirror sites out there that can replace
> > > > > content
> > > > > you get.
> > > > > There is a risk that use of a compromised trusted apt PGP key
> > > > > will not
> > > > > be noticed.  Attackers are also in a good position to deny
> > > > > themselves
> > > > > out of their actions if they are careful.
> > > > > Part of my effort is to inventory all trusted private keys
> > > > > that
> > > > > a
> > > > > distribution needs to manage on their own, or depend on that
> > > > > are managed
> > > > > by others, and gain some insight how these keys are handled.
> > > > > Does the Debian project, or any members, publish information
> > > > > on
> > > > > these
> > > > > topics?  Has this been discussed before?
> > > > > Some questions that I think would be useful to answer
> > > > > include:
> > > > > 1) List of relevant private keys, held by the organization,
> > > > > its
> > > > > members,
> > > > >     or someone else.  As far as I can tell from Debian, the
> > > > > list includes
> > > > >     the following PGP trust anchors:
> > > > >    B8B8 0B5B 623E AB6A D877  5C45 B7C5 D7D6 3509 47F8
> > > > >    05AB 9034 0C0C 5E79 7F44  A8C8 254C F3B5 AEC0 A8F0
> > > > >    4D64 FEC1 19C2 0290 67D6  E791 F8D2 585B 8783 D481
> > > > >    1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
> > > > >    AC53 0D52 0F2F 3269 F5E9  8313 A484 4904 4AAD 5C5D
> > > > >    A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793
> > > > >    80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
> > > > >    5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA
> > > > >    6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517
> > > > >     Compromising any single key on this list leads to
> > > > > trouble.
> > > > > However I
> > > > >     don't think this list is complete.  What other keys are
> > > > > there?
> > > > >     I believe there are keys used to sign some component of
> > > > > the
> > > > > boot
> > > > >     phase, compare the 'shim-signed' and 'grub-efi-amd64-
> > > > > signed'
> > > > >     packages.  What private keys held by Debian are involved
> > > > > here?  What
> > > > >     keys held by others are involved?  What other similar
> > > > > packages
> > > > >     exists?
> > > > > 2) For each private key, information about its management and
> > > > > lifecycle.
> > > > >     Relevant questions include:
> > > > >   a) How was the key generated?  By whom?  On what hardware? 
> > > > > What
> > > > >  software?  In what environment?  What legal jurisdiction
> > > > > apply to
> > > > >  people involved?
> > > > >   b) How is the key stored and protected during its
> > > > > lifetime? 
> > > > > What
> > > > > media
> > > > >  is used?  Who control the physical storage of the key? 
> > > > > How are they
> > > > >  stored and transported?  What jurisdiction?
> > > > >   c) Under what policy is the key used?  

Re: Transparency into private keys of Debian

[Simon Josefsson]

tis 2024-02-06 klockan 16:50 +0100 skrev Hans-Christoph Steiner:
> 
> 
> Simon Josefsson:
> > Hans-Christoph Steiner  writes:
> > 
> > > Thanks for digging in here, its very important work!  I'd be
> > > happy to
> > > contribute where I can.  I'm a DD and a core contributor to F-
> > > Droid,
> > > where we wrestle with basically the same issues.  So we've
> > > thought a
> > > lot about these kinds of things, but definitely do not have all
> > > the
> > > answers.  Since F-Droid started much later than Debian, we were
> > > able
> > > to build in some nice protections from the beginning, like
> > > requiring
> > > HTTPS.  We've also made the decision to stick with a single
> > > jurisdiction for the singing keys, even though it is not the best
> > > one
> > > for our needs.  We'd of course love to move them to the best
> > > jurisdiction but that is actually quite a bit of work, so we have
> > > to
> > > stay grounded in reality.
> > > 
> > > For me the hard part of all this is how to be transparent as
> > > possible
> > > without putting a giant target on the heads of the people who
> > > control
> > > the keys.  I think it is clear that publishing private key usage
> > > information is safe, like this key signed these things at these
> > > times.
> > > Publishing all the details about how the key was generated could
> > > help
> > > those who want to attack it more than those who rely on it.  But
> > > that
> > > kind of information would be good to share internally to the
> > > project
> > > at the very least.
> > 
> > Good aspect -- and indeed this is a trade-off, and thanks for
> > caring
> > about these issues for f-droid!  It seems that if you would verify
> > signatures via a transparency log, you would reduce the risk on the
> > people controlling the keys?  Then you (and they) could feel more
> > comfortable publishing information how your process work. That
> > would be
> > valuable to publish (even de-personalized or generalized) as a best
> > practices approach.  The reason is that anyone stealing the keys
> > from
> > these persons would ALSO have to upload signatures of whatever they
> > wanted to use these keys for into the transparency log, which would
> > provide evidence to what they did, so they may be less likely to
> > follow
> > through on their plans.
> 
> Yes, I agree, and am familiar with this architecture.  The hard part
> is the 
> availability of the transparency log needs to be as good as the
> signed index's 
> availability, otherwise attackers can just block the transparency log
> to stop 
> the whole process.  The official F-Droid client does a lot of things 
> automatically in order to find a working mirror.  And we're expanding
> on that. 
> I have yet to see a transparency log set up for decentralized,
> flexible 
> distribution.  F-Droid's mirror handling will automatically choose
> from:
> 
> * f-droid.org
> * Any of the official mirrors
> * Any mirrors that the user has added locally
> * Files hosted on IPFS
> * Mirrors on local storage (SD cards, thumb drives, etc)
> 
> We're expanding to:
> * Mirrors on cloud file storage like Nextcloud, Google Drive, etc.
> * Signed JSON on public code distribution platforms and CDNs

I believe sigsum allows for offline verification of the inclusion
proof.  Just include the transparency checksum proof with the app or
meta-data around the app.  Not sure about Sigstore.

> (As a side note: I would like to see Debian/apt adopt this approach,
> at least 
> optionally.  The key part is automatic operation and dead simple
> setup, e.g. for 
> non-technical users.)

+1

> > What would be involved is to 1) during signing of artifacts, also
> > sign
> > and upload into Sigstore/Sigsum, and 2) during verification in the
> > f-droid app, also verify that the signature has been committed to
> > the
> > Sigstore/Sigsum logs.  Both projects have clients written in Go
> > which
> > should work on Android, but the rest of the details are sketchy to
> > me.
> > I'm happy to continue discuss and help with design if you are
> > interested, to understand what the limitations of your environments
> > are
> > and how to resolve them.
> 
> I've looked at Sigstore, it looks nice.  It seems to be architected
> for use 
> cases that assume highly reliable and unblocked single domains. 
> That's a 
> showstopper for us.  Also, the official client app is 100% 

Re: Transparency into private keys of Debian

[Simon Josefsson]

Stephan Verbücheln  writes:

> II. Typical Debian case
>
> 1. Debian developer signs source tarballs and upload them
> 2. The signature only has to be secure until the code lands in the FTP
> 3. Debian builds the binary packages
> 4. Debian creates Release files with hashes of the packages
> 5. The Release file is signed by Debian APT keys
> 6. The signature has to be secure until the next Release file
> 7. Security updates have a separate Release file with expiration time
>
> This strategy effectively prevents attackers from injecting outdated
> programs with known vulnerabilities into the updates. Even mirrors
> cannot do that. TLS for mirrors is not required for integrity and
> authenticity.

Thanks for summarizing.  I'm not concerned with injecting outdated
programs -- I'm concerned with injecting malware indirectly signed by
the Debian APT keys, and want to explore ways to mitigate against those
attacks.

Understanding the private key lifecycle is one way to increase
confidence in what the cost of those attacks are -- right now all we can
say is that the cost of forging signatures for Debian APT keys is likely
higher than $0 and is likely lower than, let's say, $100B to pay someone
to get the keys or inject code for malicious remote signing.  Tightening
these bounds, using some rational methodology, gives us knowledge about
safety.

Using transparency logging of the signatures created by the private keys
is another way to allow detection when this occur, which also increase
confidence in the overall security, and reduce the risk with the private
keys (since they are longer useful for deniable attacks).

It may be that publishing more details about the private key lifecycle
is not a good idea unless we have measurements to protect ourselves, but
at least establishing that fact would be an improvement, and an
incentive to invest in these improvements.

/Simon


signature.asc
Description: PGP signature

Re: Transparency into private keys of Debian

[Simon Josefsson]

Bill Allombert  writes:

> On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote:
>> Bill Allombert  writes:
>> 
>> > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit :
>> >> Hi
>> >> 
>> >> I'm exploring how to defend against an attacker who can create valid
>> >> signatures for cryptographic private keys (e.g., PGP) that users need to
>> >> trust when using an operating system such as Debian.  A signature like
>> >> that can be used in a targetted attacks against one victim.
>> >> 
>> >> For example, apt does not have any protection against this threat
>> >> scenario, 
>> >
>> > Is not apt-key a protection ?
>> 
>> No, the current implementation protects against missing and/or invalid
>> signatures.  Compare how in the WebPKI world some CA issued a valid
>> *.google.com certificate, and how that (and other incidents) lead to
>> setup of Certificate Transparency, which helps mitigate these issues.
>
> The difference is that with apt-key, the list of valid public keys is stored 
> on
> the user system (in /etc/apt/trusted.gpg.d/), not a list of root certificates,
> and that the users are notified when the keys are updated, which is not the
> case with CA.  Nobody can generate a new signature that will be accepted by
> apt-key out of the box.

Right, there are differences, but I believe the underlying problem is
the same: if someone mis-use private keys I trust, or is able to forge
valid signatures somehow (e.g., crypto attack), apt-key wouldn't notice
but in the WebPKI world there are mechanisms to mitigate this via
Certificate Transparency.

It is a subjective choice to care about this attack scenario, and some
may regard it as out of scope, but others can believe it is in scope and
that improvements are warranted.

/Simon


signature.asc
Description: PGP signature

Re: Transparency into private keys of Debian

[Simon Josefsson]

Hans-Christoph Steiner  writes:

> Thanks for digging in here, its very important work!  I'd be happy to
> contribute where I can.  I'm a DD and a core contributor to F-Droid,
> where we wrestle with basically the same issues.  So we've thought a
> lot about these kinds of things, but definitely do not have all the
> answers.  Since F-Droid started much later than Debian, we were able
> to build in some nice protections from the beginning, like requiring
> HTTPS.  We've also made the decision to stick with a single
> jurisdiction for the singing keys, even though it is not the best one
> for our needs.  We'd of course love to move them to the best
> jurisdiction but that is actually quite a bit of work, so we have to
> stay grounded in reality.
>
> For me the hard part of all this is how to be transparent as possible
> without putting a giant target on the heads of the people who control
> the keys.  I think it is clear that publishing private key usage
> information is safe, like this key signed these things at these times.
> Publishing all the details about how the key was generated could help
> those who want to attack it more than those who rely on it.  But that
> kind of information would be good to share internally to the project
> at the very least.

Good aspect -- and indeed this is a trade-off, and thanks for caring
about these issues for f-droid!  It seems that if you would verify
signatures via a transparency log, you would reduce the risk on the
people controlling the keys?  Then you (and they) could feel more
comfortable publishing information how your process work. That would be
valuable to publish (even de-personalized or generalized) as a best
practices approach.  The reason is that anyone stealing the keys from
these persons would ALSO have to upload signatures of whatever they
wanted to use these keys for into the transparency log, which would
provide evidence to what they did, so they may be less likely to follow
through on their plans.

What would be involved is to 1) during signing of artifacts, also sign
and upload into Sigstore/Sigsum, and 2) during verification in the
f-droid app, also verify that the signature has been committed to the
Sigstore/Sigsum logs.  Both projects have clients written in Go which
should work on Android, but the rest of the details are sketchy to me.
I'm happy to continue discuss and help with design if you are
interested, to understand what the limitations of your environments are
and how to resolve them.

/Simon

> And publishing the jurisdictions could be enough info to deanonymize
> the key holder, e.g. if it is Germany, then there are many DDs there.
> If it is Iceland, then govs can easily find who to target.
>
> .hc
>
>> Hi
>> I'm exploring how to defend against an attacker who can create valid
>> signatures for cryptographic private keys (e.g., PGP) that users need to
>> trust when using an operating system such as Debian.  A signature like
>> that can be used in a targetted attacks against one victim.
>> For example, apt does not have any protection against this threat
>> scenario, and often unprotected ftp:// or http:// transports are used,
>> which are easy to man-in-the-middle.  Even with https:// there is a
>> large number of mirror sites out there that can replace content you get.
>> There is a risk that use of a compromised trusted apt PGP key will not
>> be noticed.  Attackers are also in a good position to deny themselves
>> out of their actions if they are careful.
>> Part of my effort is to inventory all trusted private keys that a
>> distribution needs to manage on their own, or depend on that are managed
>> by others, and gain some insight how these keys are handled.
>> Does the Debian project, or any members, publish information on
>> these
>> topics?  Has this been discussed before?
>> Some questions that I think would be useful to answer include:
>> 1) List of relevant private keys, held by the organization, its
>> members,
>>or someone else.  As far as I can tell from Debian, the list includes
>>the following PGP trust anchors:
>>   B8B8 0B5B 623E AB6A D877  5C45 B7C5 D7D6 3509 47F8
>>   05AB 9034 0C0C 5E79 7F44  A8C8 254C F3B5 AEC0 A8F0
>>   4D64 FEC1 19C2 0290 67D6  E791 F8D2 585B 8783 D481
>>   1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
>>   AC53 0D52 0F2F 3269 F5E9  8313 A484 4904 4AAD 5C5D
>>   A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793
>>   80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
>>   5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA
>>   6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517
>>Compromising any single key on this list leads to trouble.
>> However I
>>don't think this list is complete.  What other keys are there?
>>I believe there are keys used to sign some component of the boot
>>phase, compare the 'shim-signed' and 'grub-efi-amd64-signed'
>>packages.  What private keys held by Debian are involved here?  What
>>keys 

Re: Transparency into private keys of Debian

[Simon Josefsson]

Bill Allombert  writes:

> Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit :
>> Hi
>> 
>> I'm exploring how to defend against an attacker who can create valid
>> signatures for cryptographic private keys (e.g., PGP) that users need to
>> trust when using an operating system such as Debian.  A signature like
>> that can be used in a targetted attacks against one victim.
>> 
>> For example, apt does not have any protection against this threat
>> scenario, 
>
> Is not apt-key a protection ?

No, the current implementation protects against missing and/or invalid
signatures.  Compare how in the WebPKI world some CA issued a valid
*.google.com certificate, and how that (and other incidents) lead to
setup of Certificate Transparency, which helps mitigate these issues.
It is possible to implement similar features for the relevant private
keys used to sign Debian too; Sigstore and Sigsum are two publicly
available projects.

/Simon


signature.asc
Description: PGP signature

Transparency into private keys of Debian

[Simon Josefsson]

Hi

I'm exploring how to defend against an attacker who can create valid
signatures for cryptographic private keys (e.g., PGP) that users need to
trust when using an operating system such as Debian.  A signature like
that can be used in a targetted attacks against one victim.

For example, apt does not have any protection against this threat
scenario, and often unprotected ftp:// or http:// transports are used,
which are easy to man-in-the-middle.  Even with https:// there is a
large number of mirror sites out there that can replace content you get.
There is a risk that use of a compromised trusted apt PGP key will not
be noticed.  Attackers are also in a good position to deny themselves
out of their actions if they are careful.

Part of my effort is to inventory all trusted private keys that a
distribution needs to manage on their own, or depend on that are managed
by others, and gain some insight how these keys are handled.

Does the Debian project, or any members, publish information on these
topics?  Has this been discussed before?

Some questions that I think would be useful to answer include:

1) List of relevant private keys, held by the organization, its members,
   or someone else.  As far as I can tell from Debian, the list includes
   the following PGP trust anchors:

  B8B8 0B5B 623E AB6A D877  5C45 B7C5 D7D6 3509 47F8
  05AB 9034 0C0C 5E79 7F44  A8C8 254C F3B5 AEC0 A8F0
  4D64 FEC1 19C2 0290 67D6  E791 F8D2 585B 8783 D481
  1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
  AC53 0D52 0F2F 3269 F5E9  8313 A484 4904 4AAD 5C5D
  A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793
  80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
  5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA
  6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517

   Compromising any single key on this list leads to trouble.  However I
   don't think this list is complete.  What other keys are there?

   I believe there are keys used to sign some component of the boot
   phase, compare the 'shim-signed' and 'grub-efi-amd64-signed'
   packages.  What private keys held by Debian are involved here?  What
   keys held by others are involved?  What other similar packages
   exists?

2) For each private key, information about its management and lifecycle.
   Relevant questions include:

 a) How was the key generated?  By whom?  On what hardware?  What
software?  In what environment?  What legal jurisdiction apply to
people involved?

 b) How is the key stored and protected during its lifetime?  What media
is used?  Who control the physical storage of the key?  How are they
stored and transported?  What jurisdiction?

 c) Under what policy is the key used?  What should it sign?  Who
authorize the signing?  What hardware and software is used?  What
jurisdiction?

 d) For externally held keys, what are the legal terms we use the keys
under?  What insight into key transparency questions do we have?
What of those can we make public?  How do they restrict what we are
allowed to do?

3) Which less visible private keys are indirectly trusted by users of
   the distribution?  For example, all DD PGP keys are indirectly
   trusted since they are permitted to make uploads into the archive.
   Host keys used to authorized access to sensitive systems may also be
   relevant.  I'm primarily thinking SSH private keys to a system that
   may have online access to a private key signing oracle.  Indirectly,
   questions about authentication protocols and authorization methods
   are relevant.

To the extent that symmetric shared secrets (rather than asymmetric
public/private keys) are involved, the same question applies.

Other aspects worth exploring?

I understand commercial distributions have different incentives related
to making this information public.  They have a commercial interest to
defend, and has usually entered various legal arrangements that create
obstacles related to releasing information.  As we've seen with the
WebPKI CA business, that model does not inspire trust and leads to
systematic failures.  More transparent approaches like Certificate
Transparency and LetsEncrypt evolved as a consequence.

I believe that Debian is in a good position to improve things and, if
there is interest, could lead the way by documenting a better approach,
and describe how to deal with these concerns in a more transparent way
than what we do today.

Thoughts?

/Simon


signature.asc
Description: PGP signature

Bug#1061446: ITP: cosign -- Code signing and transparency for containers and binaries

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: cosign
  Version : 2.2.2-1
  Upstream Author : The Sigstore Authors
* URL : https://github.com/sigstore/cosign
* License : Apache-2.0
  Programming Lang: Go
  Description : Code signing and transparency for containers and binaries

 Signing OCI containers (and other artifacts) using Sigstore
 (https://sigstore.dev/)!
 .
 Go Report Card
 (https://goreportcard.com/report/github.com/sigstore/cosign) e2e-tests
 (https://github.com/sigstore/cosign/actions/workflows/e2e-tests.yml) CII
 Best Practices
 (https://bestpractices.coreinfrastructure.org/projects/5715) OpenSSF
 Scorecard
 (https://api.securityscorecards.dev/projects/github.com/sigstore/cosign)
 .
 Cosign aims to make signatures **invisible infrastructure**.
 .
 Cosign supports:
 .
  * "Keyless signing" with the Sigstore public good Fulcio certificate
authority and Rekor transparency log (default)
  * Hardware and KMS signing
  * Signing with a cosign generated encrypted private/public keypair
  * Container Signing, Verification and Storage in an OCI registry.
  * Bring-your-own PKI
 .
 Info
 .
 Cosign is developed as part of the sigstore (https://sigstore.dev)
 project. We also use a slack channel (https://sigstore.slack.com)! Click
 here (https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-
 XmY3bcfWn4XEyMqUUutbUQ) for the invite link.
 .
 Installation
 .
 For Homebrew, Arch, Nix, GitHub Action, and Kubernetes installs see the
 installation docs
 (https://docs.sigstore.dev/system_config/installation/).
 .
 For Linux and macOS binaries see the GitHub release assets
 (https://github.com/sigstore/cosign/releases/latest).
 .
 :rotating_light: If you are downloading releases of cosign from our GCS
 bucket - please see more information on the July 31, 2023 deprecation
 notice (https://blog.sigstore.dev/cosign-releases-bucket-deprecation/)
 :rotating_light:
 .
 Developer Installation
 .
 If you have Go 1.19+, you can setup a development environment:
 .
   $ git clone https://github.com/sigstore/cosign
   $ cd cosign
   $ go install ./cmd/cosign
   $ $(go env GOPATH)/bin/cosign
 .
 Contributing
 .
 If you are interested in contributing to cosign, please read the
 contributing documentation (/CONTRIBUTING.md).
 .
 Dockerfile
 .
 Here is how to install and use cosign inside a Dockerfile through the
 gcr.io/projectsigstore/cosign image:
 .
   FROM gcr.io/projectsigstore/cosign:v1.13.0 as cosign-bin
 .
   # Source: https://github.com/chainguard-images/static
   FROM cgr.dev/chainguard/static:latest
   COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
   ENTRYPOINT [ "cosign" ]
 .
 Quick Start
 .
 This shows how to:
 .
  * sign a container image with the default "keyless signing" method (see
KEYLESS.md (/KEYLESS.md))
  * verify the container image
 .
 Sign a container and store the signature in the registry
 .
 Note that you should always sign images based on their digest
 (@sha256:...) rather than a tag (:latest) because otherwise you might
 sign something you didn't intend to!
 .
cosign sign $IMAGE
 .
   Generating ephemeral keys...
   Retrieving signed certificate...
 .
Note that there may be personally identifiable information associated
 with this signed artifact.
This may include the email address associated with the account with
 which you authenticate.
This information will be used for signing this artifact and will be
 stored in public transparency logs and cannot be removed later.
 .
   By typing 'y', you attest that you grant (or have permission to grant)
 and agree to have this information stored permanently in transparency
 logs.
   Are you sure you would like to continue? [y/N] y
   Your browser will now be opened to:
 .
 
https://oauth2.sigstore.dev/auth/auth?access_type=online_id=sigstore_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY_challenge_method=S256=2KvOWeTFxYfxyzHtssvlIXmY6Jk_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback_type=code=openid+email=2KvOWfbQJ1caqScgjwibzK2qJmb
   Successfully verified SCT...
   tlog entry created with index: 12086900
   Pushing signature to: $IMAGE
 .
 Cosign will prompt you to authenticate via OIDC, where you'll sign in
 with your email address. Under the hood, cosign will request a code
 signing certificate from the Fulcio certificate authority. The subject
 of the certificate will match the email address you logged in with.
 Cosign will then store the signature and certificate in the Rekor
 transparency log, and upload the signature to the OCI registry alongside
 the image you're signing.
 .
 Verify a container
 .
 To verify the image, you'll need to pass in the expected certificate
 issuer and certificate subject via the --certificate-identity and --
 certificate-oidc-issuer flags:
 .
   cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-
 issuer=$OIDC_ISSUER
 .
 You can also pass 

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Simon Josefsson]

Luca Boccassi  writes:

> On Wed, 24 Jan 2024 at 13:34, Simon Josefsson  wrote:
>>
>> Luca Boccassi  writes:
>>
>> >> Having reflected a bit, and learned through my own experience and
>> >> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> >> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> >> package and the resulting package rebuilds:
>> >
>> > There's always option B: recognize that the Rust/Go ecosystems are not
>> > designed to be compatible with the Linux distributions model
>>
>> Definitely - that's roughly the model we have today, right?  So no
>> action needed to preserve status quo of option B.
>>
>> I want to explore if there is a possibility to change status quo, and
>> what would be required to do so.
>
> What's required is talking to the language ecosystem owners and
> convince them to support a stable ABI and dynamic linking, and in
> general to care about the distribution use case. Otherwise it's just
> an unwinnable uphill battle that consumes a ton of scarce resources
> (developers time), and is simply hopeless.

One could equally well make the argument that distributors should care
about the Go/Rust ecosystems, and make whatever changes needed in order
to support them.  Those changes are what I'm trying to explore here.

Speaking as a C person (I know little about Go/Rust), getting stable
ABIs, dynamic linking and security upgrades right is not simple, and
we've been working on that for 20+ years consuming plenty of human
resources on the way.

/Simon


signature.asc
Description: PGP signature

Re: Proposal for how to deal with Go/Rust/etc security bugs

[Simon Josefsson]

Luca Boccassi  writes:

>> Having reflected a bit, and learned through my own experience and
>> others' insights [1] that Go Build-Depends are not transitive, I'd like
>> to update my proposal on how to handle a security bug in any Go/Rust/etc
>> package and the resulting package rebuilds:
>
> There's always option B: recognize that the Rust/Go ecosystems are not
> designed to be compatible with the Linux distributions model

Definitely - that's roughly the model we have today, right?  So no
action needed to preserve status quo of option B.

I want to explore if there is a possibility to change status quo, and
what would be required to do so.

Given how often gnulib is vendored for C code in Debian, and other
similar examples, I don't think of this problem as purely a Go/Rust
problem.  The parallel argument that we should not support coreutils,
sed, tar, gzip etc because they included vendored copies of gnulib code
is not reasonable.

> and are instead designed to be as convenient as possible for a
> _single_ application developer and its users - at the detriment of
> everybody else - and for large corporations that ship a handful of
> applications with swathes of engineers that can manage the churn, and
> it is not made nor intended to scale to ~60k packages or whatever
> number we have today in unstable. And simply stop attempting to merge
> these two incompatible ecosystems against their will, at the very
> least until and unless they reach feature and stability parity with
> the C/C++ ecosystems - stable API/ABI and dynamic linking by default.

Go seems to have supported shared libraries since around ca 2015:

https://go.dev/talks/2015/state-of-go-may.slide#13
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit

Does anyone know of a shared library in a Debian package written in Go?
I've only encountered the vendored approach to ship Go libraries.

> There are many ways to ship applications today that are much better
> suited for these models, like Flatpak, where the maintenance burden is
> shifted onto those who choose to opt in to such ecosystems.

Or simply 'go install ...', it works remarkably well.

However, this is orthogonal to how we support the Go code that is in
Debian already.

/Simon


signature.asc
Description: PGP signature

Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

[Simon Josefsson]

Simon Josefsson  writes:

>> > My naive approach on how to fix a security problem in package X
>> > which is
>> > statically embedded into other packages A, B, C, ... would be to
>> > rebuild
>> > the transitive closure of all packages that Build-Depends on X and
>> > publish a security update for all those packages.
...
> I realized that there is one problem with my approach: consider if
> package A was built via Build-Depends package B of version X and that
> later package B is upgraded to X+1 in Debian.  Then if a security
> problem happens in B we need to rebuild A. It may be that package A no
> longer builds due to some incompatibility between version X and X+1 of
> B.  This would not be noticed until a full rebuild of an archive is
> done, or when the security teams wants to rebuild the transitive
> closure of the Build-Depends graph for a package.

Having reflected a bit, and learned through my own experience and
others' insights [1] that Go Build-Depends are not transitive, I'd like
to update my proposal on how to handle a security bug in any Go/Rust/etc
package and the resulting package rebuilds:

  To fix a security problem in package X, which is used during build
  (through statical linking, vendoring, or some other mechanism) to
  build package A, B, C, ... you need to rebuild all packages that
  Build-Depends on X (lets call this step 1) and all packages that
  Build-Depends on any of the packages that will be rebuilt during step
  1.  This rebuild process is iterated until no more packages remains to
  be rebuild, and all packages have been rebuilt using newly rebuild
  packages.  If there are cyclical dependencies (which unfortunately are
  common), you have to loop until all packages have been rebuilt with a
  clean dependency chain, and detect the loop and stop rebuilding.  If
  there are FTBFS errors during the rebuilds, this will have to be
  patched too.

Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this
will mean rebuilding almost all of the Go packages in Debian and publish
them in a security advisory.

This algorithm can be optimized (i.e., reduce the number of packages to
publish in an advisory) by either of:

1) using information from Built-Using: (which was not designed for
   this purpose, so this is fragile) or *.buildinfo.

2) by dropping all 'Architecture: all' packages that does not embedd
   the buggy code.

The last optimization 2) would reduce the number of Go packages to
publish significantly, as it would drop most golang-*-dev packages.  I
think this actually makes this process feasible in practice, as there
are relatively few binary packages written in Go.

This method applies to non-Go/Rust too, if there are such security
problems and reverse build chains.

I think all of this (except maybe the optimization 2) which requires
code comparisons) can be automated in a GitLab pipeline for higher
confidence of the result.

/Simon

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806481#58


signature.asc
Description: PGP signature

Bug#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: sigsum-go
  Version : 1.7.1-1
  Upstream Author : The Sigsum Project Authors
* URL : https://git.glasklar.is/sigsum/core/sigsum-go
* License : BSD-2-Clause
  Programming Lang: Go
  Description : tools for public and transparent logging of signed checksums

 The goal of Sigsum is to provide building blocks that can be used to
 enforce public logging of signed checksums.
 .
 This package contains the sigsum-key, sigsum-submit, sigsum-verify,
 and sigsum-monitor command line tools.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/sigsum-go

/Simon


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

Adam Borowski  writes:

> On Mon, Jan 15, 2024 at 10:17:17AM +0100, Bastian Blank wrote:
>> On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote:
>> > Isn't that what the text refers to?  Vendoring and static linking are
>> > two examples of the same problem that the security team may encounter.
>> 
>> We accept vendoring of autoconf/automake/gnulib distro wide.
>
> We _did_ accept that in the past, but these days you get smacked with a RC
> bug for not building from source.

What do you mean?  Can you show me _any_ package in Debian that
re-bootstrap itself using gnulib during package build?  If by source you
mean the source code in gnulib, not the vendored version shipping with
many packages.

If a security bug is found in gnulib code, one approach to fix it would
be to patch the Debian gnulib package, and then automatically rebuild
all packages that uses that gnulib function.

I believe it is rare for packages in Debian to re-bootstrap itself from
gnulib sources.  Look at coreutils, sed, grep, tar, wget, libidn2, etc,
none of them do that.  Certainly not a RC bug.

The situation now when a security bug in gnulib is found, you will have
to patch all packages using that code manually per-package.

>> The vendoring of gnulib, well, is old and maybe you could
>> show that it is a problem in the sources that have it, aka they don't
>> handle security fixes and at the same time don't change the library.
>
> Gnulib has not been useful for ages, thus packages still shipping vendored
> copies are harmless -- functions that gnulib was meant to provide
> implementation for were missing on ancient unices like HP-UX or SCO that
> are long dead by now.  A glance at recent commits in gnulib shows a lot of
> retrocomputing names: Windows, OS/2, MacOS 10.5, AIX, on hardware of that
> level of recency.  It's not used for new ports: the most recent reference
> to riscv in commit messages is from _2018_.

I think you underestimate how often gnulib is used, and how well it
works on modern platforms, and how much gnulib code is used that's not
in glibc or other system shared libraries.  I assume coreutils, sed,
tar, gzip etc were important bootstrapping packages for riscv, and they
all build fine thanks in large extent due to gnulib being written in a
architecture independent way.

/Simon


signature.asc
Description: PGP signature

Bug#1061050: ITP: golang-github-common-nighthawk-go-figure -- Prints ASCII art from text

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-common-nighthawk-go-figure
  Version : 0.0~git20210622.734e95f-1
  Upstream Author : Daniel Deutsch
* URL : https://github.com/common-nighthawk/go-figure
* License : Expat
  Programming Lang: Go
  Description : Prints ASCII art from text

 Go Figure prints beautiful ASCII art from text. It supports FIGlet
 (http://www.figlet.org/) files, and most of its features.
 .
 This package was inspired by the Ruby gem artii
 (https://github.com/miketierney/artii), but built from scratch and with
 a different feature set.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-common-nighthawk-go-figure

/Simon


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

Bastian Blank  writes:

> On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
>> Rebuilding a bit more than what is strictly needed sounds fine as a
>> first solution to me.
>
> Building maybe.  But how do you want to publish them?  The security
> archive is not made to handle that.

What is the limitation?  Is it human time involved to rebuild and QA
packages?  Or the technical infrastructure related to publish security
fixes?  Or the hosting infrastructure to deliver the package upgrades
via security.debian.org?  Or something else?

>> My naive approach on how to fix a security problem in package X which is
>> statically embedded into other packages A, B, C, ... would be to rebuild
>> the transitive closure of all packages that Build-Depends on X and
>> publish a security update for all those packages.
>
> So if a fix to the net/tls module of go shows up (happens from time to
> time), all go packages needs to be rebuilt?

All Go packages that are affected by the security problem of net/tls,
yes.  That seems to be how the Go eco-system want things to be, the
static linking nature is by design.  Whether that is a good or bad
design can be discussed, but it seems intentional and won't go away.

My main point is that we have this situation in Debian already.  Maybe
vendoring via gnulib is a better example than config.h or statical
linking though.

Having being more exposed to the packaging aspects of Go projects in
Debian recently, I am more sympathetic towards being conservative about
offering security claims for these packages though.  I wouldn't envy
anyone trying to resolve a security vulnerability for a Go package in
bookworm with many reverse dependencies.  OTOH, I don't think it is
sustainable to ignore security vulnerabilities in software that we ship.
We just have to find a technical solution to solve whatever problems
prevent us from being able to do that.

/Simon


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

"IOhannes m zmölnig (Debian GNU|Linux)"  writes:

> On 1/16/24 13:56, Jérémy Lal wrote:
>>>
>>> As Built-Using is for license compliance only, no?
>>>
>>> See
>>>
>>> https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
>> Indeed, thanks for the link.
>> 
>
> it seems that many people think that "Built-Using" can be used to
> express static linking (including yours truly, even though i *know*
> that it is meant for license compliance only).
>
> which makes me wonder: probably we should have an additional field
> that expresses such static linking (and therefore would trigger a
> rebuild when the dependency changes).
> or we could finally accept that many¹ people would just use
> "Built-Using" for this anyhow, and explicitly allow such use.

Would that be better or worse than making *.buildinfo files more
generally available and required?

Buildinfo files appears to have some traction already, and it seems like
they could help address the same problem.

Unfortunately *.buildinfo still seems hard to access reliably and their
integrity aren't protected by the archive-wide InRelease signature, if I
understand correctly.

/Simon


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

tis 2024-01-16 klockan 11:22 +0100 skrev Jérémy Lal:
> 
> 
> Le mar. 16 janv. 2024 à 11:00, Simon Josefsson 
> a écrit :
> > Paul Wise  writes:
> > 
> > > On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:
> > > 
> > > > I asked for practical solutions, not theoretical ones.  We
> > > > don't have a
> > > > suitable way to rebuild all packages just because right now.
> > > 
> > > There are some ideas on the static linking wiki page:
> > > 
> > > https://wiki.debian.org/StaticLinking
> > > 
> > > Probably the most practical solution for today would be to use a
> > > build
> > > info database to find out which builds had installed binary
> > > packages
> > > containing insecure statically linkable files of any kind, then
> > > rebuild
> > > the source packages that were affected. There is a 2019 demo
> > > here:
> > > 
> > > https://salsa.debian.org/bremner/builtin-pho/-/blob/master/demos/needs-rebuild.sh
> > > https://www.cs.unb.ca/~bremner//blog/posts/builtin-pho/
> > > 
> > > This may mean rebuilding more packages than were really needed,
> > > but a more exact method would require full tracing of input data
> > > to
> > > output data during builds being added to all toolchains, which
> > > seems
> > > like a much longer term project than buildinfo based rebuilds.
> > 
> > Rebuilding a bit more than what is strictly needed sounds fine as a
> > first solution to me.
> > 
> > My naive approach on how to fix a security problem in package X
> > which is
> > statically embedded into other packages A, B, C, ... would be to
> > rebuild
> > the transitive closure of all packages that Build-Depends on X and
> > publish a security update for all those packages.
> > 
> > What is the problem with that approach to handle security problems
> > in a
> > Go package for trixie?
> > 
> > I'm sure the number of packages to rebuild could be reduced in
> > various
> > clever ways, but until we have tooling to automate that, a naive
> > but
> > costly approach seems feasible, unless i'm missing something.
> > 
> > How large is the gap between tracing buildinfo information and
> > simply
> > relying on Build-Depends?
> > 
> > Isn't the gap between using Build-Depends and the buildinfo-
> > approach
> > only concerning the always-assumed-to-be-installed packages like
> > libc or
> > /bin/sh which I never seems to recall if they are what build-
> > essential
> > installs, or what the policy manual says it should do, or what
> > 'Essential: yes' implies, or 'Priority: required' implies, etc. 
> > For Go
> > packages I don't think they are relevant in practice.
> > 
> 
> 
> I naively believed that golang-* packages expressed those
> dependencies with "Built-Using".

True, but I was thinking of a solution that would not be Go-specific.

I realized that there is one problem with my approach: consider if
package A was built via Build-Depends package B of version X and that
later package B is upgraded to X+1 in Debian.  Then if a security
problem happens in B we need to rebuild A. It may be that package A no
longer builds due to some incompatibility between version X and X+1 of
B.  This would not be noticed until a full rebuild of an archive is
done, or when the security teams wants to rebuild the transitive
closure of the Build-Depends graph for a package.

I still think this is something we just need to be prepared to handle,
by patching packages to fix the build problem in whatever way is
appropriate.  It will require some more patching to really fix the
security problem, and allow packages to be rebuilt with the new
version.

/Simon



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

Re: Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

Paul Wise  writes:

> On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote:
>
>> I asked for practical solutions, not theoretical ones.  We don't have a
>> suitable way to rebuild all packages just because right now.
>
> There are some ideas on the static linking wiki page:
>
> https://wiki.debian.org/StaticLinking
>
> Probably the most practical solution for today would be to use a build
> info database to find out which builds had installed binary packages
> containing insecure statically linkable files of any kind, then rebuild
> the source packages that were affected. There is a 2019 demo here:
>
> https://salsa.debian.org/bremner/builtin-pho/-/blob/master/demos/needs-rebuild.sh
> https://www.cs.unb.ca/~bremner//blog/posts/builtin-pho/
>
> This may mean rebuilding more packages than were really needed,
> but a more exact method would require full tracing of input data to
> output data during builds being added to all toolchains, which seems
> like a much longer term project than buildinfo based rebuilds.

Rebuilding a bit more than what is strictly needed sounds fine as a
first solution to me.

My naive approach on how to fix a security problem in package X which is
statically embedded into other packages A, B, C, ... would be to rebuild
the transitive closure of all packages that Build-Depends on X and
publish a security update for all those packages.

What is the problem with that approach to handle security problems in a
Go package for trixie?

I'm sure the number of packages to rebuild could be reduced in various
clever ways, but until we have tooling to automate that, a naive but
costly approach seems feasible, unless i'm missing something.

How large is the gap between tracing buildinfo information and simply
relying on Build-Depends?

Isn't the gap between using Build-Depends and the buildinfo-approach
only concerning the always-assumed-to-be-installed packages like libc or
/bin/sh which I never seems to recall if they are what build-essential
installs, or what the policy manual says it should do, or what
'Essential: yes' implies, or 'Priority: required' implies, etc.  For Go
packages I don't think they are relevant in practice.

/Simon


signature.asc
Description: PGP signature

Bug#1060853: ITP: golang-github-sigstore-protobuf-specs -- Sigstore Protocol Buffer code (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sigstore-protobuf-specs
  Version : 0.2.1-1
  Upstream Author : sigstore
* URL : https://github.com/sigstore/protobuf-specs
* License : Apache-2.0
  Programming Lang: Go
  Description : Sigstore Protocol Buffer code (library)

 This repository holds protobuf specifications for Sigstore messages.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sigstore-protobuf-specs

/Simon


signature.asc
Description: PGP signature

Bug#1060852: ITP: golang-bitbucket-creachadair-shell -- implements basic shell command-line splitting for Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-bitbucket-creachadair-shell
  Version : 0.0.8-1
  Upstream Author : Michael J. Fromberger
* URL : https://bitbucket.org/creachadair/shell/
* License : BSD-3-Clause
  Programming Lang: Go
  Description : implements basic shell command-line splitting for Go 
(library)

 Provides supports for splitting and joining of shell command strings.
 .
 The Split function divides a string into whitespace-separated fields,
 respecting single and double quotation marks as defined by the Shell Command
 Language section of IEEE Std 1003.1 2013.  The Quote function quotes
 characters that would otherwise be subject to shell evaluation, and the Join
 function concatenates quoted strings with spaces between them.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-bitbucket-creachadair-shell/

/Simon


signature.asc
Description: PGP signature

Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: trillian
  Version : 1.6.0-1
  Upstream Author : Google
* URL : https://github.com/google/trillian
* License : Apache-2.0
  Programming Lang: Go
  Description : A transparent, highly scalable and cryptographically 
verifiable data store

 Trillian is an implementation of the concepts described in the
 Verifiable Data Structures (/docs/papers/VerifiableDataStructures.pdf)
 white paper, which in turn is an extension and generalisation of the
 ideas which underpin Certificate Transparency (https://certificate-
 transparency.org).
 .
 Trillian implements a Merkle tree
 (https://en.wikipedia.org/wiki/Merkle_tree) whose contents are served
 from a data storage layer, to allow scalability to extremely large
 trees.  On top of this Merkle tree, Trillian provides the following:
 .
  * An append-only **Log** mode, analogous to the original
Certificate Transparency (https://certificate-transparency.org) logs.
In
this mode, the Merkle tree is effectively filled up from the left,
giving a
*dense* Merkle tree.
 .
 Certificate Transparency (CT) (https://tools.ietf.org/html/rfc6962) is
 the most well-known and widely deployed transparency application, and an
 implementation of CT as a Trillian personality is available in the
 certificate-transparency-go repo (https://github.com/google/certificate-
 transparency-go/blob/master/trillian).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/trillian

/Simon


signature.asc
Description: PGP signature

Bug#1060841: ITP: golang-github-transparency-dev-merkle -- create and manipulate Merkle trees in Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-transparency-dev-merkle
  Version : 0.0.2-1
  Upstream Author : Pavel Kalinnikov, Al Cutter, Martin Hutchinson, M Hickford, 
et al
* URL : https://github.com/transparency-dev/merkle
* License : Apache-2.0
  Programming Lang: Go
  Description : create and manipulate Merkle trees in Go (library)

 Provides Go code to help create and manipulate Merkle trees, as well as
 constructing and verifying various types of proof.
 .
 This is the data structure which is used by projects such as Trillian
 (https://github.com/google/trillian) to provide verifiable logs
 (https://transparency.dev/verifiable-data-structures/#verifiable-log).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-transparency-dev-merkle

/Simon


signature.asc
Description: PGP signature

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-k8s-sigs-release-utils
  Version : 0.7.7-1
  Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/release-utils
* License : Apache-2.0
  Programming Lang: Go
  Description : utilities for kubernetes Go release engineering (library)

 Tiny utilities for use by the Release Engineering subproject and
 kubernetes/release (https://github.com/kubernetes/release/).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-k8s-sigs-release-utils

/Simon


signature.asc
Description: PGP signature

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-adamkorcz-go-fuzz-headers-1
  Version : 0.0~git20230919.8b5d3ce-1
  Upstream Author : Adam Korcz 
* URL : https://github.com/AdamKorcz/go-fuzz-headers-1
* License : Apache-2.0
  Programming Lang: Go
  Description : helper functions for Go fuzzing (library)

 Various helper functions for go fuzzing. It is mostly used in combination
 with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
 fuzzing in the standard library will also be supported. Any coverage guided
 fuzzing engine that provides an array or slice of bytes can be used with
 go-fuzz-headers.
 .
 go-fuzz-headers' approach to fuzzing structs is strongly inspired by
 gofuzz (https://github.com/google/gofuzz).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/

/Simon


signature.asc
Description: PGP signature

Bug#1060836: ITP: golang-github-cavaliergopher-rpm -- A Go implementation of the RPM file format

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-cavaliergopher-rpm
  Version : 1.2.0-1
  Upstream Author : Ryan Armstrong, et al
* URL : https://github.com/cavaliergopher/rpm
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go implementation of the RPM file format (library)

 This implements the rpm package file format as a Go library
 .
 See the package documentation
 (https://pkg.go.dev/github.com/cavaliergopher/rpm) to get started.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-cavaliergopher-rpm

/Simon


signature.asc
Description: PGP signature

Bug#1060834: ITP: golang-github-veraison-go-cose -- go library for CBOR Object Signing and Encryption (COSE)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-veraison-go-cose
  Version : 1.2.1-1
  Upstream Author : Veraison
* URL : https://github.com/veraison/go-cose
* License : MPL-2.0
  Programming Lang: Go
  Description : go library for CBOR Object Signing and Encryption (COSE)

 A golang library for the COSE specification
 (https://datatracker.ietf.org/doc/rfc9052/)

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-veraison-go-cose

/Simon


signature.asc
Description: PGP signature

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-cyberphone-json-canonicalization
  Version : 0.0~git20220623.57a0ce2-1
  Upstream Author : Anders Rundgren
* URL : https://github.com/cyberphone/json-canonicalization
* License : Apache-2.0
  Programming Lang: Go
  Description : JSON Canonicalization Scheme (JCS) (Go library)

 Cryptographic operations like hashing and signing depend on that the
 target data does not change during serialization, transport, or parsing.
 By applying the rules defined by JCS (JSON Canonicalization Scheme),
 data provided in the JSON [RFC8259
 (https://tools.ietf.org/html/rfc8259)] format can be exchanged "as is",
 while still being subject to secure cryptographic operations. JCS
 achieves this by building on the serialization formats for JSON
 primitives as defined by ECMAScript [ES (https://ecma-
 international.org/ecma-262/)], constraining JSON data to the I-JSON
 [RFC7493 (https://tools.ietf.org/html//rfc7493)] subset, and through a
 platform independent property sorting scheme.
 .
 Public RFC: (https://tools.ietf.org/html/rfc8785)
 .
 The JSON Canonicalization Scheme concept in a nutshell:
 .
  * Serialization of primitive JSON data types using methods compatible
with ECMAScript's JSON.stringify()
  * Lexicographic sorting of JSON Object properties in a *recursive*
process
  * JSON Array data is also subject to canonicalization, *but element
order remains untouched*

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-cyberphone-json-canonicalization

/Simon


signature.asc
Description: PGP signature

Bug#1060819: ITP: golang-github-zeebo-errs -- errs is a package for making errors friendly and easy

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-zeebo-errs
  Version : 1.3.0-1
  Upstream Author : Jeff Wendling
* URL : https://github.com/zeebo/errs
* License : Expat
  Programming Lang: Go
  Description : errs is a Go library for making errors friendly and easy

 errs is a package for making errors friendly and easy.  Errors come
 with a stack trace that is only printed when a "+" character is used in
 the format string. This should retain the benefits of being able to
 diagnose where and why errors happen, without all of the noise of
 printing a stack trace in every situation.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-zeebo-errs/

/Simon


signature.asc
Description: PGP signature

Bug#1060818: ITP: in-toto-golang -- framework for software supply chain integrity

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: in-toto-golang
  Version : 0.9.0-1
  Upstream Author : Aditya Sirish, Christian Rebischke, Lukas Pühringer, et al
* URL : https://github.com/in-toto/in-toto-golang
* License : Apache-2.0
  Programming Lang: Go
  Description : framework for software supply chain integrity

 Go implementation of in-toto

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/in-toto-golang/

/Simon



signature.asc
Description: PGP signature

Bug#1060817: ITP: golang-github-spiffe-go-spiffe -- Golang library for SPIFFE support

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-spiffe-go-spiffe
  Version : 2.1.6-1
  Upstream Author : Agustín Martínez Fayó, Andrew Harding, et al
* URL : https://github.com/spiffe/go-spiffe
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang library for SPIFFE support

 This library is a convenient Go library for working with SPIFFE
 (https://spiffe.io/).
 .
 It leverages the SPIFFE Workload API
 (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Workload_API.md),
 providing high level functionality that includes:
 .
  * Establishing mutually authenticated TLS (**mTLS**) between workloads
powered by SPIFFE.
  * Obtaining and validating X509-SVIDs
(https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md) and
JWT-SVIDs (https://github.com/spiffe/spiffe/blob/main/standards/JWT-
SVID.md).
  * Federating trust between trust domains using SPIFFE bundles

(https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#3-
spiffe-bundles).
  * Bundle management.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-spiffe-go-spiffe/

/Simon


signature.asc
Description: PGP signature

Bug#1060816: ITP: golang-github-shibumi-go-pathspec -- gitignore-style pathspec pattern matching in Go

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-shibumi-go-pathspec
  Version : 1.3.0-1
  Upstream Author : Sander van Harmelen, Christian Rebischke
* URL : https://github.com/shibumi/go-pathspec
* License : Apache-2.0
  Programming Lang: Go
  Description : gitignore-style pathspec pattern matching in Go

 go-pathspec implements gitignore-style pattern matching for paths.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-shibumi-go-pathspec/

/Simon


signature.asc
Description: PGP signature

Bug#1060815: ITP: relic -- digitally sign Linux/Java/Windows packages

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: relic
  Version : 7.6.1-1
  Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/relic
* License : Apache-2.0
  Programming Lang: Go
  Description : digitally sign Linux/Java/Windows packages

 relic is a multi-tool and server for package signing and working with
 hardware security modules (HSMs).
 .
 Package types
 .
  * RPM - RedHat packages
  * DEB - Debian packages
  * JAR - Java archives
  * EXE (PE/COFF) - Windows executable
  * MSI - Windows installer
  * appx, appxbundle - Windows universal application
  * CAB - Windows cabinet file
  * CAT - Windows security catalog
  * XAP - Silverlight and legacy Windows Phone applications
  * PS1, PS1XML, MOF, etc. - Microsoft Powershell scripts and modules
  * manifest, application - Microsoft ClickOnce manifest
  * VSIX - Visual Studio extension
  * Mach-O - macOS/iOS signed executables
  * DMG, PKG - macOS disk images / installer packages
  * APK - Android package
  * PGP - inline, detached or cleartext signature of data
 .
 Token types
 .
 relic can work with several types of token:
 .
  * pkcs11 - Industry standard PKCS#11 HSM interface using shared object
files
  * Cloud services - AWS, Azure and Google Cloud managed keys
  * scdaemon - The GnuPG scdaemon service can enable access to OpenPGP
cards (such as Yubikey NEO)
  * file - Private keys stored in a password-protected file
 .
 Features
 .
 Relic is primarily meant to operate as a signing server, allowing
 clients to authenticate with a TLS certificate and sign packages
 remotely. It can also be used as a standalone signing tool.
 .
 Other features include:
 .
  * Generating and importing keys in the token
  * Importing certificate chains from a PKCS#12 file
  * Creating X509 certificate signing requests (CSR) and self-signed
certificates
  * Limited X509 CA support -- signing CSRs and cross-signing certificates
  * Creating simple PGP public keys
  * RSA and ECDSA supported for all signature types
  * Verify signatures, certificate chains and timestamps on all supported
package types
  * Sending audit logs to an AMQP broker, with an optional sealing
signature
  * Save token PINs in the system keyring
 .
 Linux, Windows and MacOS are supported. Other platforms probably work as
 well.
 .
 relic is tested using libsofthsm2 and Gemalto SafeNet Network HSM (Luna
 SA).

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/relic

/Simon


signature.asc
Description: PGP signature

Bug#1060813: ITP: golang-github-qur-ar -- Golang ar archive file library

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-qur-ar
  Version : 0.0~git20130629.282534b-1
  Upstream Author : Blake Smith, Julian Phillips
* URL : https://github.com/qur/ar
* License : Expat
  Programming Lang: Go
  Description : Golang ar archive file library

 Golang ar (archive) file reader
 .
 This is a simple library for reading and writing ar
 (http://en.wikipedia.org/wiki/Ar_(Unix)) files in common format. It is
 influenced heavily in style and interface from the golang tar
 (http://golang.org/pkg/archive/tar/) package.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-qur-ar

/Simon


signature.asc
Description: PGP signature

Bug#1060810: ITP: golang-github-sassoftware-go-rpmutils -- Golang implementation of parsing RPM packages

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sassoftware-go-rpmutils
  Version : 0.2.0-1
  Upstream Author : SAS Institute, Inc.
* URL : https://github.com/sassoftware/go-rpmutils
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang implementation of parsing RPM packages

 go-rpmutils is a library written in go (http://golang.org) for parsing
 and extracting content from RPMs (http://www.rpm.org).
 .
 go-rpmutils provides a few interfaces for handling RPM packages. There is
 a highlevel Rpm struct that provides access to the RPM header and CPIO
 (https://en.wikipedia.org/wiki/Cpio) payload. The CPIO payload can be
 extracted to a filesystem location via the ExpandPayload function or
 through a Reader interface, similar to the tar implementation
 (https://golang.org/pkg/archive/tar/) in the go standard library.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sassoftware-go-rpmutils

/Simon


signature.asc
Description: PGP signature

Re: Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

Bastian Blank  writes:

> Hi Simon
>
> On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote:
>> As an analogy, consider the ./configure scripts that is generated by
>> autoconf during build of many packages.  The script typically generate
>> code that is put into config.h that is used (statically) during
>> compilation of the binaries that are shipped by Debian.
>
> Could you show an example, where there is actually code injcted in this
> stage?  And then, this is vendoring, not static linking.
>
>> You could also compare how the source-level reuse-library gnulib is used
>> by many essential packages (coreutils, grep, sed, awk, tar, etc), with
>> large code-reuse that influences the installed binaries.  A security
>> sensitive bug in gnulib would require rebuild of many packages.
>
> That is not static linking, this is vendoring.  And can you show that
> GNU utils don't fix security bugs on this vendored lib?
>
>> My suggestion is that we relax or remove the Go/Rust statement in future
>> release notes.
>
> No.  You described completely different circumstances.
>
> Or do you have a practical solution for the static linking problem, not
> the vendoring problem that you actually compared it against?

Right, these are slightly different technical problems, but as far as
the brief discussion in the release notes --
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking
-- I think the relevant aspect is identical: package X in Debian
contains an embedded copy of code whose corresponding source code is in
package Y in Debian, and fixing a security problem in Y will require
rebuilding X and the entire dependency chain between X and Y that carry
the code that ends up in X.

Isn't that what the text refers to?  Vendoring and static linking are
two examples of the same problem that the security team may encounter.
The problem with dependencies are more obvious for Go/Rust code but I
think we always have had that problem anyway.

As for solutions, isn't the solution to both vendoring or statical
linking the obvious one?  You will have to rebuild all packages that
contain the security vulnerability.

Maybe I'm missing how these two problems result in different problems
for the security team?

/Simon


signature.asc
Description: PGP signature

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Bastian Blank  writes:

> On Fri, Dec 29, 2023 at 11:30:14AM +0100, Simon Josefsson wrote:
>> * Package name: ssh3
>
> This package name is clearly not acceptable.  SSH is a well known name
> and this project is completely unrelated to it.

Agreed.  Packagers have settled on using 'soh' for the name, see:

https://github.com/francoismichel/ssh3/issues/79
https://github.com/francoismichel/ssh3/pull/96

Once 0.1.5 is released, I will try to update the package to use the new
name.  It doesn't seem to collide with anything in Debian, as far as I
can tell.  It would be nice to have confirmation other distributions are
going to use the same name, but I think we have that in the discussion
above.  Thoughts?

Hyperbole in package descriptions are common, the current text is from
the upstream authors and I think it makes sense to copy that in the
package description.  If you can think of some improvement, consider
submitting a patch: https://salsa.debian.org/go-team/packages/ssh3

/Simon


signature.asc
Description: PGP signature

Limited security support for Go/Rust? Re ssh3

[Simon Josefsson]

Stephan Verbücheln  writes:

> On Sat, 30 Dec 2023 12:47:48 + Colin Watson 
> wrote:
>> I also feel that something security-critical like this that's
>> labelled by upstream as "still experimental" probably shouldn't
>> be in a Debian release.
>
> It is written in Go. The problem of Go library support in Debian should
> also be considered for a security-critical tool like this.
>
> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking

Interesting -- what is the current thinking about this problem?

The more I think about it, I think it seems unfair to categorize this as
a Go/Rust problem.

As an analogy, consider the ./configure scripts that is generated by
autoconf during build of many packages.  The script typically generate
code that is put into config.h that is used (statically) during
compilation of the binaries that are shipped by Debian.  Consider
further that these configure scripts would put security buggy into
config.h, coming from autoconf internally or some wildly used M4 macros.
How would the security team handle that situation?  Perhaps by patching
autoconf to fix the problem and rebuild all the packages that are
affected by that bug, and release them as a (potentially large) security
update.  This is a similar situation to the Go/Rust problem that the
link above describes.

Yes I know, historically config.h has been quite small, so the problem
hasn't been that significant, but have a look at a config.h from a
couple of large project today.  Compare an earlier large-scale-affecting
build-tool bug in automake --
https://lists.gnu.org/archive/html/automake/2012-07/msg00022.html --
which happened to have mild consequences because 'make distcheck' is
rarely run by most users or even during package builds, and the
generated code didn't end up in the installed binaries.  But it could
happen in a 'make all' or a 'make check' target too, or affect code that
actually influence the installed binaries.

You could also compare how the source-level reuse-library gnulib is used
by many essential packages (coreutils, grep, sed, awk, tar, etc), with
large code-reuse that influences the installed binaries.  A security
sensitive bug in gnulib would require rebuild of many packages.

My suggestion is that we relax or remove the Go/Rust statement in future
release notes.

/Simon


signature.asc
Description: PGP signature

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Colin Watson  writes:

> On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote:
>> On 29.12.23 11:30, Simon Josefsson wrote:
>> > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
>> > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
>> > secure channel establishment and the HTTP Authorization mechanisms for
>> > user authentication. Among others, SSH3 allows the following
>> > improvements:
>> 
>> I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for
>> the concatenation of SSH and H3." - well sure, but you're also reusing the
>> name of an existing protocol and bump its version. ssh-h3?
>
> I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
> cause a new source of user confusion because people will think "ah,
> ssh3, that must be better than ssh" (which indeed seems to have been a
> deliberate marketing choice by this project) and not realize that it's a
> largely incompatible thing.  Not to mention the way that it parses
> OpenSSH configuration files, which may work today but I doubt OpenSSH
> offers any guarantees that it won't make changes that will break this
> independent parser in future.

I share these concerns, so I'll delay the upload for now.  I'm hoping
upstream will rename the project to something less confusing.

> I also feel that something security-critical like this that's labelled
> by upstream as "still experimental" probably shouldn't be in a Debian
> release.  Maybe it should be kept in Debian experimental for the time
> being?

Sounds good if nothing happens on the naming front in the next
weeks/months.  Let's wait and see a bit.

One alternative that was suggested was to call the package something
else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
as long as the 'ssh3' name is in there.

/Simon


signature.asc
Description: PGP signature

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Packaging of SSH3 is available here:

https://salsa.debian.org/go-team/packages/ssh3
https://salsa.debian.org/jas/ssh3/

Thanks to the Salsa CI/CD pipeline there is an aptly repository
available for easy testing, if anyone would like to experiment or help.

Below you can find a snippet how you can test the SSH3 client and server
via Debian packages, for password and public key authentication, in a
safe container using podman.  I have only tested this on my laptop that
runs Trisquel, but should hopefully be portable.

I am delaying upload to Debian for a while to see if upstream reaches a
conclusion around naming.  I think the name 'ssh3' is unfortunate and
distracts from the effort. See:
.

/Simon

sudo apt install podman
podman run -it --hostname myhost.example --rm debian:unstable
cd
apt update
apt dist-upgrade -y
apt install -y ca-certificates
echo "deb [trusted=yes] 
https://salsa.debian.org/jas/ssh3/-/jobs/5094673/artifacts/raw/aptly unstable 
main" | tee /etc/apt/sources.list.d/ssh3.list
apt update
apt install -y ssh3

apt install -y ssl-cert # creates snakeoil key/cert

passwd # set a test password for 'root' e.g. 'foo'

ssh3-server -cert /etc/ssl/certs/ssl-cert-snakeoil.pem -key 
/etc/ssl/private/ssl-cert-snakeoil.key -enable-password-login -url-path /myurl 
-v &

ssh3 -v -insecure -use-password myhost.example/myurl
# type 'foo' at the prompt, and on successful connection type 'exit' to log out

apt install -y openssh-client # for ssh-keygen
ssh-keygen -t ed25519 -P "" -f /root/.ssh/id_ed25519
cat /root/.ssh/id_ed25519.pub > /root/.ssh3/authorized_identities
ssh3 -v -insecure -privkey /root/.ssh/id_ed25519 myhost.example/myurl
# on successful connection type 'exit' to log out


signature.asc
Description: PGP signature

Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Philipp Kern  writes:

> On 29.12.23 11:30, Simon Josefsson wrote:
>> Package: wnpp
>> Severity: wishlist
>> X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
>> * Package name: ssh3
>>Version : 0.1.4
>>Upstream Contact: François Michel
>> * URL : https://github.com/francoismichel/ssh3
>> * License : Apache-2.0
>>Programming Lang: Go
>>Description : faster and rich secure shell using HTTP/3
>> SSH3 is a complete revisit of the SSH protocol, mapping its
>> semantics on
>> top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
>> secure channel establishment and the HTTP Authorization mechanisms for
>> user authentication. Among others, SSH3 allows the following
>> improvements:
>
> I feel like SSH3 is an unfortunate name. The program claims "SSH3
> stands for the concatenation of SSH and H3." - well sure, but you're
> also reusing the name of an existing protocol and bump its
> version. ssh-h3?
>
> Both the paper and the project are very new - so there should not be
> that many things referring to it yet.

I agree the name is unfortunate.  There are discussions with upstream in
https://github.com/francoismichel/ssh3/issues/79 and via emails.

I have packaging in https://salsa.debian.org/go-team/packages/ssh3 but I
will hold of uploading to NEW until some time has past to see if we
there will be a rename, and to give it more time for testing.  I have
managed to install the packages and start a server and make a client
connection to it.

/Simon


signature.asc
Description: PGP signature

Bug#1059620: ITP: golang-github-golang-jwt-jwt-v5 -- golang implementation of JSON Web Tokens (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-golang-jwt-jwt-v5
  Version : 5.2.0-1
  Upstream Author : golang-jwt maintainers, Dave Grijalva
* URL : https://github.com/golang-jwt/jwt
* License : Expat
  Programming Lang: Go
  Description : golang implementation of JSON Web Tokens (library)

I have working packaging of this here:

https://salsa.debian.org/jas/jwt-v5/

I hope to maintain it in the Debian Go Packaging group eventually.

This package appears to be required by the 'ssh3' package, and the
existing golang-github-golang-jwt-jwt package is stuck on the old ABI
and it looks like it will never upgrade, see:
https://tracker.debian.org/pkg/golang-github-golang-jwt-jwt

/Simon


signature.asc
Description: PGP signature

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

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

* Package name: ssh3
  Version : 0.1.4
  Upstream Contact: François Michel
* URL : https://github.com/francoismichel/ssh3
* License : Apache-2.0
  Programming Lang: Go
  Description : faster and rich secure shell using HTTP/3

SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
secure channel establishment and the HTTP Authorization mechanisms for
user authentication. Among others, SSH3 allows the following
improvements:

- Significantly faster session establishment

- New HTTP authentication methods such as OAuth 2.0 and OpenID Connect
  in addition to classical SSH authentication

- Robustness to port scanning attacks: your SSH3 server can be made
  invisible to other Internet users

- UDP port forwarding in addition to classical TCP port forwarding

- All the features allowed by the modern QUIC protocol: including
  connection migration (soon) and multipath connections

I hope this package can be maintained in the Debian Go Packaging Team.


signature.asc
Description: PGP signature

Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: si...@josefsson.org
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: apt-verify
  Version : 2.0
  Upstream Contact: Simon Josefsson 
* URL : https://gitlab.com/debdistutils/apt-verify
* License : AGPLv3+
  Programming Lang: Shell script
  Description : extend apt's gpgv-based verification mechanism

Apt-verify extends apt to call all tools in /etc/verify.d/ instead of
always only calling gpgv, to verify apt archive integrity and
authenticity.  A symbolic link in /etc/verify.d/gpgv is installed by
default to provide full backwards compatibility.

/Simon


signature.asc
Description: PGP signature

Re: Signature strength of .dsc

[Simon Josefsson]

Jonathan McDowell  writes:

> On Mon, Dec 04, 2023 at 11:07:38AM +0100, Simon Josefsson wrote:
>> Judit Foglszinger  writes:
>> >> > Dmitri, could you re-run the numbers with the debian-maintainer
>> >> > keyring?
>> >> 
>> >> That is correct. I have updated the results now.  The 2,455 no
>> >> public key has now become 1,238
>> >
>> > Another is the DN keyring.  Also I'd expect many keys to be found in
>> > older versions of the keyring package/keyring repository and on
>> > keyservers like keyserver.ubuntu.com
>> 
>> Removing old keys is usually a bad idea -- could these be moved to a
>> "archived" keyring instead?  I assume having them in the "live"
>> keyring is not possible if the presence of a key in that file is used
>> to make authorization decisions.
>> 
>> You want to be able to verify old signatures in 20+ years too, and
>> then you need to be able to find the corresponding public key.
>
> For a long time we had a "removed" keyring, but we decided that we
> didn't want to continue shipping a keyring that was explicitly a set of
> keys we could not vouch for the trust of (whether that be because they
> were revoked, lost, weak, or whatever). If you really want to find old
> keys there is 15+ years of history in the keyring git repository, as
> Judit mentioned:
>
> https://salsa.debian.org/debian-keyring/keyring/

I think that is unfortunate and not sustainable over time: you need to
have access to the public keys to verify old signatures, and for as long
as the old signatures are published we should make a public keyring for
them easily available.  Which I suspect means essentially forever, due
to archive.debian.org.

I don't think it doesn't really matter of the old public key is weak or
invalid: if we know of a public key published at the time as some
signature that was possible to verify using software available at that
time, we should publish that public key.

Was there a real practical situations that couldn't be resolved that
lead to dropping the "removed" keyring?  What was the details?  Maybe
this decision could be reverted with some effort.

/Simon


signature.asc
Description: PGP signature

Re: Signature strength of .dsc

[Simon Josefsson]

Judit Foglszinger  writes:

> Hi,
>
>> > Dmitri, could you re-run the numbers with the debian-maintainer keyring?
>> 
>> That is correct. I have updated the results now.
>> The 2,455 no public key has now become 1,238
>
> Another is the DN keyring.
> Also I'd expect many keys to be found in older versions of the keyring 
> package/keyring repository
> and on keyservers like keyserver.ubuntu.com

Removing old keys is usually a bad idea -- could these be moved to a
"archived" keyring instead?  I assume having them in the "live" keyring
is not possible if the presence of a key in that file is used to make
authorization decisions.

You want to be able to verify old signatures in 20+ years too, and then
you need to be able to find the corresponding public key.

Even finding a copy of my own old RSA1280 key 0xB565716F turned out to
be tricky, I had to search for it just a couple of days ago and I
couldn't find it on the keyservers I looked on.  The key was used during
2002-2014 to sign a lot of software releases (and emails).  Fortunately,
I had a habbit of sticking it into AUTHORS field of some packages so I
found it here:

https://git.savannah.gnu.org/cgit/libidn.git/tree/AUTHORS?id=cd51d7cd4e83f8b5240517b63ba2adef721542c9

/Simon


signature.asc
Description: PGP signature

Re: Signature strength of .dsc

[Simon Josefsson]

Salvo Tomaselli  writes:

>> hi, on "no public key" list there are my uploads, I'm debian maintainer 
>> (https://nm.debian.org/person/fantu/), I signed with my key and I have 
>> DM upload right for them 
>> (https://qa.debian.org/developer.php?login=fantonifabio%40tiscali.it)
>
> I think he just didn't check the debian-maintainer keyring at all.

Dmitri, could you re-run the numbers with the debian-maintainer keyring?

The numbers suggest to me that signing strength of DSC signatures on the
contrary really do provide value and that it is working well.  The
instances of RIPEMD160/SHA1 I checked were old, and the numbers of
failures are quite low compared to overall number of uploaded packages.
Thus we have good assurance on the majority of packages.

We should make sure RIPEMD160/SHA1 signatures are rejected going
forward, as well as the wrong-key-usage.

/Simon


signature.asc
Description: PGP signature

Bug#1042827: ITP: priv-wrapper -- library to disable resource limits and other privilege dropping

[Simon Josefsson]

Package: wnpp
Severity: wishlist

Hi!  I am planning to package priv-wrapper:

   https://cwrap.org/priv_wrapper.html

   priv_wrapper aims to help running processes which are dropping
   privileges or are restricting resources in test environments. A
   disabled call always succeeds (i.e. returns 0) and does nothing. The
   system call pledge exists only on OpenBSD.

It is similar in spirit as the rest of the cwrap projects -- see
https://cwrap.org/ -- and several seems to be packaged in Debian:

https://tracker.debian.org/pkg/nss-wrapper
https://tracker.debian.org/pkg/uid-wrapper
https://tracker.debian.org/pkg/socket-wrapper
https://tracker.debian.org/pkg/pam-wrapper

The license appears to be GPLv3+.

/Simon


signature.asc
Description: PGP signature

Re: [RFC] changes to rsyslog - default to RFC 5424 format

[Simon Josefsson]

Michael Biebl  writes:

> Hi,
>
> we are early in the bookworm release cycle, so I guess it's the
> perfect time to bring up this topic.

Sorry for hijacking the thread, but perhaps now is a good time to stop
using the legacy syslog time format and use the standardized RFC 5424
format?  It is the default format in upstream rsyslog, but the default
Debian config uses the legacy format.

Effectively, the change that I suggest is to stop putting this into
/etc/rsyslog.conf by default:

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

The legacy time format that is used today does not record year, timezone
or subsecond information.  Compare /var/log/syslog outputs like this:

Nov 23 21:47:31 latte jas: test

with

2021-11-23T21:47:49.082799+01:00 latte jas: test

/Simon


signature.asc
Description: PGP signature

Re: Debian choice of upstream tarballs for packaging

[Simon Josefsson]

Paul Wise  writes:

> Hi all,
>
> I noticed that sometimes Debian's choice of upstream source for
> packaging can be suboptimal. This is especially apparent for the
> different per-language upstream packaging ecosystems[1], where the
> upstream packaging differs from the upstream VCS in some significant
> ways, including missing files, prebuilt files, embedded copies etc.
>
> While the upstream VCS also sometimes has these issues, it is often
> much less problematic than the upstream packaging ecosystems.

While I agree with the points you raise, and think I agree with your
overall goal, I see some problems with using upstream VCS as a source
for Debian packaging:

1) Trust paths.  Some upstreams sign release tarballs with an OpenPGP
release key that Debian trust for making releases.  Not all upstream
uses the same key to sign VCS tags/commits, and not all upstreams sign
VCS tags/commits at all.  While Debian can encourage and promote new
policies for upstream here, I don't think we are in a position to
require any uniform set of rules.  Signing tarballs is the current
established best practice -- moving to VCS builds needs a set of new
schemes to be established and deployed, and I don't see any single
universal solution today.

2) Bootstrapping projects from VCS is complex and requires additional
tools, and I think the Debian packaging process is well suited for this.
Two examples that I have run into:

  2a) Gnulib.  Several GNU-related projects import files from gnulib
  during VCS bootstrapping, and the way this happens is different for
  different projects.  The correct version of the files must be imported
  in the right way for things to work, and knowledge of which gnulib
  version is used is not always present in VCS but only in a released
  tarball.  How would this work when packaged in Debian?  A debian
  package containing the gnulib git repository could be added, to allow
  source packages to checkout the right version during build.

  2b) Cross-compilation and dependency cycles.  Bootstrapping from VCS
  may require a lot of tools that are optional when building from
  tarball, and in my experience the complete set of tools to bootstrap a
  project is rarely added as Build-Dep to Debian packages.  I feel some
  additional package build dependency mechanism would help here: maybe a
  Build-Bootstrap-Dep header to list the tools needed to generate a
  Debian source package?  And Build-Dep could list the tools needed to
  build Debian binary packages from the Debian source package.  I admit
  my understanding of the Debian packaging system is quite limited
  though.

3) Bootstrappable builds.  I think the underlying goal when it comes to
building from VCS may be to achieve bootstrappable builds -- see
https://www.bootstrappable.org/ -- however it seems to me that a lot of
care has to be taken when moving from tarball builds to VCS builds so we
don't make it harder to re-bootstrap the entire toolchain.  For example,
building GNU Coreutils from a tarball works fine in extremely old
environments, but building GNU Coreutils from VCS requires modern tools,
and perhaps some of them doesn't support older environments any more.

/Simon


signature.asc
Description: PGP signature

Re: Planning for libidn shared library version transition

[Simon Josefsson]

Hi!  I'm now resuming work on the libidn shared library transition, and
I'm ready for the upload to experimental.  I wanted to ping back here to
get more review.  I'm following Andreas Metzler's outline, but included
some tweaks suggested by Simon McVittie.  I decided to do some more
changes that are unrelated here (e.g., drop the would-be poorly named
libidn11-java package which nobody appears to use, and drop the no
longer working Emacs libraries).

The old package (1.33-3, in bullseye) looks like the following (yeah,
the 'Replaces: libidn11-dev' on the 'libidn11' package is confusing, and
could potentially cause problems here):

Package: libidn11
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Conflicts: libidn9-dev
Replaces: libidn11-dev
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
Description: GNU Libidn library, implementation of IETF IDN specifications

Package: libidn11-dev
Section: libdevel
Architecture: any
Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
Conflicts: libidn9-dev
Multi-Arch: same
Description: Development files for GNU Libidn, an IDN library

The new package (1.38-1) that I'm planning to upload has this:

Package: libidn12
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
Description: GNU Libidn library, implementation of IETF IDN specifications

Package: libidn-dev
Section: libdevel
Architecture: any
Depends: libidn12 (= ${binary:Version}), pkg-config, ${misc:Depends}
Breaks: libidn11-dev (<< 1.38-1~)
Replaces: libidn11-dev (<< 1.38-1~)
Suggests: idn
Multi-Arch: same
Description: Development files for GNU Libidn, an IDN library

Package: libidn11-dev
Section: oldlibs
Architecture: any
Depends: libidn-dev (>= 1.38-1~), ${misc:Depends}
Multi-Arch: same
Description: Transitional development package for GNU Libidn

Libidn11-dev's '>= 1.38-1~' dependency, and the '<< 1.38-1~' in
libidn12, came as a suggestion from Simon McVittie.

It builds fine, and reverse dependencies builds too (the two failures
are not libidn-issues):
https://salsa.debian.org/debian/libidn/-/pipelines/270968

I'm including more complete debdiff below.

What do you think?

I'm not only looking to catch fatal mistakes, but also want ideas on how
to improve this further, so all feedback is welcome.

Thanks,
/Simon

jas@latte:~/dpkg$ debdiff --show-moved libidn_1.33-3_amd64.changes 
libidn_1.38-1_amd64.changes 
Warning: these package names were in the second list but not in the first:
--
libidn-dev
libidn12
libidn12-dbgsym


Warning: these package names were in the first list but not in the second:
--
libidn11
libidn11-dbgsym
libidn11-java

[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files only in first set of .debs, found in package idn
--
-rw-r--r--  root/root   /usr/share/doc/idn/AUTHORS.gz
-rw-r--r--  root/root   /usr/share/doc/idn/TODO
-rw-r--r--  root/root   /usr/share/emacs/site-lisp/idna.el
-rw-r--r--  root/root   /usr/share/emacs/site-lisp/punycode.el

Files only in first set of .debs, found in package idn-dbgsym
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/b8/51518b886fad3ef49ddda44ba667ac043e60c0.debug

Files only in first set of .debs, found in package libidn11
---
-rw-r--r--  root/root   /lib/x86_64-linux-gnu/libidn.so.11.6.16
-rw-r--r--  root/root   /usr/share/doc/libidn11/changelog.Debian.gz
-rw-r--r--  root/root   /usr/share/doc/libidn11/changelog.gz
-rw-r--r--  root/root   /usr/share/doc/libidn11/copyright
lrwxrwxrwx  root/root   /lib/x86_64-linux-gnu/libidn.so.11 -> libidn.so.11.6.16

Files moved from package libidn11 to package libidn12
-
-rw-r--r--  root/root   DEBIAN/shlibs
-rw-r--r--  root/root   DEBIAN/symbols
-rw-r--r--  root/root   DEBIAN/triggers

Files only in first set of .debs, found in package libidn11-dbgsym
--
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/14/d4bc0771a40445c675c5c4682d56465463ccc8.debug
lrwxrwxrwx  root/root   /usr/share/doc/libidn11-dbgsym -> libidn11

Files only in first set of .debs, found in package libidn11-dev
---
-rw-r--r--  root/root   /usr/share/doc-base/libidn11
-rw-r--r--  root/root   /usr/share/doc/libidn11-dev/examples/README
-rw-r--r--  root/root   /usr/share/doc/libidn11-dev/examples/example.c
-rw-r--r--  root/root   /usr/share/doc/libidn11-dev/examples/example2.c
-rw-r--r--  root/root   /usr/share/doc/libidn11-dev/examples/example3.c
-rw-r--r--  root/root   

Re: Planning for libidn shared library version transition

[Simon Josefsson]

Simon McVittie  writes:

> On Wed, 26 May 2021 at 19:18:24 +0200, Simon Josefsson wrote:
>> Andreas Metzler  writes:
>> > Why not use a versioned Provides *instead* of the dummy package?
>> 
>> Yeah, I never understand exactly when these dummy packages are needed.
>
> My understanding is that they are usually still necessary for smooth
> upgrades from one stable release to the next, because apt's dependency
> resolver tries not to remove packages (to minimize risk of removing
> something you were relying on), and removing a "real" libidn11-dev
> package because its lockstep version dependency is no longer satisfiable
> will still count as removing a package, even if a new libidn-dev now
> Provides it.
>
> It's a probabilistic thing, because apt calculates a "score" for various
> options for the whole upgrade transaction and chooses the one with the
> highest score - on some systems it will be able to figure out the right
> upgrade transaction even without a transitional package, but on others it
> will not. Having a transitional package makes it more likely that the
> intended upgrade happens, because apt gives a high "score" to upgrading a
> package that was already installed.
>
> piuparts only routinely tests relatively small installations - there are
> periodic QA tests done on larger systems like the union of all desktop
> tasks, but those are more expensive to run.

Thanks -- you convinced me to prefer libidn is not a guinea pig for
testing something like this.  I do think it would be a wortwhile release
goal, at some point, to fix tooling so that dummy packages are no longer
necessary for package transitions.  The information to make proper
decisions for 'apt' should be there without using dummy packages, as far
as I understand.  On the other hand, there are probably more important
areas (say, 100% reproducible builds) to work on instead.

/Simon


signature.asc
Description: PGP signature

Re: Planning for libidn shared library version transition

[Simon Josefsson]

Andreas Metzler  writes:

> On 2021-05-26 Guillem Jover  wrote:
>> On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote:
> [...]
>> I'd probably instead make this a versioned Provides, so that the
>> transitional package can be removed right away from systems, it does
>> not interfere with the transition, and people can switch to the new
>> package in parallel w/o disruption.
>
> Hello,
>
> Why not use a versioned Provides *instead* of the dummy package? We have
> had these a long time our packagment management system should have 100%
> support now.

Yeah, I never understand exactly when these dummy packages are needed.
Before I remembered about dummy packages, I tested a libidn update
without it, and it appeared to build reverse dependencies just fine
(piuparts/reprotest).  The only answer I have seen is that 'some of our
old tooling behaved strange' if you didn't have a dummy transitional
package, without specific references to actual tools or versions.

Maybe we can try a transition without a dummy package, and use it as an
experiment to see what breaks?  I suspect that after a release, it is a
good time to do it.

/Simon


signature.asc
Description: PGP signature

Re: Planning for libidn shared library version transition

[Simon Josefsson]

Andreas Metzler  writes:

> On 2021-05-24 Simon Josefsson  wrote:
>> Hi!  This is for post-bullseye, but I appreciate guidance if anyone has
>> time.  Shared library version transitions trigger uncertainty in me.
>
>> I want to upload a new upstream libidn release into Debian, but upstream
>> has done a shared library transition.
>
> Hello Simon,
>
> I will assume that "shared library transition" means that that libidn
> 1.34 will have a soname bump (libidn12.so) but that the new release is
> API compatible. The following assumes this is true ...

Hi.  Thanks for review!

For all practical matters, yes, it is completely API compatible, the
only thing that changed was this struct (that should never have been in
the public .h anyway) that changed from:

  struct Stringprep_table
  {
Stringprep_profile_steps operation;
Stringprep_profile_flags flags;
const Stringprep_table_element *table;
  };
  typedef struct Stringprep_table Stringprep_profile;

into:

  struct Stringprep_table
  {
Stringprep_profile_steps operation;
Stringprep_profile_flags flags;
const Stringprep_table_element *table;
size_t table_size;
  };
  typedef struct Stringprep_table Stringprep_profile;

Arguably, doing a soname bump for this minor change could probably have
been avoided, but this was back in 2018 and other distributions have
upgraded to newer libidn.  If we revert the soname upstream now, it will
cause a lot of problems for others, so I don't think that is a good
idea.

We could patch upstream in Debian to avoid the soname bump, but that is
rather confusing.  It is good timing now to fix this once bullseye is
released, so I think we should just do that.

>> Bullseye will ship with
>> libidn11-dev instead of libidn-dev too.  Is the first step on the
>> transition to provide a libidn-dev package experimental (and after the
>> release, unstable) and make all reverse build-dependencies use it?
>
> That would delay the whole thing unnecessarily, you would not want to
> artificially make changing all rdeps a pre-dependency of your work
>
> First off if the new version of libidn is API compatible with 1.33 there
> will be no hard /requirement/ for renaming libidn11-dev to libidn12-dev.
> You could have libidn11-dev as a dev-package for libidn12. It is not
> aesthetically pleasing and confusing but would continue to work and has
> the least potential for error. OTOH a soname bump is good time for
> renaming the development package since you will have a new binary
> package (libidn12) and will need to go through NEW processing anyway.
> However you should do soname bump and  dev-package rename in one upload
> (to experimental) instead of beforehand. This ways ftp-master will only
> need to check it once. So you would use this timelime:
>
> 1. Prepare packages of the new upstream targeted for experimental
> (libidn12, libidn-dev, libidn11-dev transition package). Test.
> 2. Upload to experimental.
> 3. Wait for NEW processing
> 4. Do some more tests, once you thinks all rdeps could be built against
> libidn12 you request a transition slot. Please note that at this point
> no source changes to rdeps related to packaging changes needed to happen,
> they can (and should) continue to b-d on libidn11-dev which pulls in the
> libidn-dev.
> 5. debian-release gives you the GO for uploading the package to testing.
> 6. You do this and debian-release triggers rebuilds of all rdeps.
> 7. All rebuilt rdeps and libidn12/libidn-dev/libidn11-dev propagate to
> testing together 10 days later.
> 8. Now you can start submitting bug-reports against rdeps asking for a
> change of the b-d.

That (and your suggestions below) seems good.  I like it better than my
approach.  I'll start to implement this and post a debdiff for review
before actually making the upload into experimental.

/Simon

> [...]
>> A 'git diff' between the version in bullseye and what I want to upload
>> to experimental is shown below, together with debdiff-output between the
>> built packages.
>
>> Generally, does things looks okay?  Specifically, what about the
>> Breaks/Replaces/Conflicts?  The d/changelog entry?  Will the confusing
>> 'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
>> any problem?  Am I right to drop it here?
>
>>  Package: libidn11-dev
>> +Section: oldlibs
>> +Architecture: any
>> +Depends: libidn-dev, ${misc:Depends}
>
> I would use (= ${binary:Version}) for the depends to make sure that
> libidn11-dev 1.38 together with libidn-dev 1.34 do not fullfill a
> dependency on libidn11-dev (>= 1.35)
>
>> +Package: libidn-dev
>>  Section: libdevel
>>  Architecture: any
>>  Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}

Re: Planning for libidn shared library version transition

[Simon Josefsson]

mån 2021-05-24 klockan 20:45 +0200 skrev Timo Röhling:
> Hi Simon!
> 
> * Simon Josefsson  [2021-05-24 19:34]:
> > I want to upload a new upstream libidn release into Debian, but
> > upstream
> > has done a shared library transition. 
> You should probably read the Release Team documentation [1] on
> library transitions if you haven't done so already.

Thanks -- I will take a look.

> > Is the first step on the transition to provide a libidn-dev package
> > experimental (and after the release, unstable) and make all reverse
> > build-dependencies use it?
> Generally, it is a good idea to have a libidn-dev package instead of
> libidn11-dev, so +1 on that. It will avoid sourceful uploads of
> reverse-dependencies in the future.

Indeed.

> However, I noticed that Debian ships with the successor library
> libidn2 already, and its homepage says it provides a compatibility
> layer for libidn. So wouldn't it be better to sunset libidn in favor
> of the new version?

It would, but there are still some valid reasons for using libidn
(e.g., stringprep), and I doubt all dependencies will be able to
migrate before bullseye+1.  I will include a comment about this in the
bugs I file, maybe some of the reverse dependencies should just stop
using libidn instead.  Still, they need to be modified anyway.

/Simon



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

Planning for libidn shared library version transition

[Simon Josefsson]

Hi!  This is for post-bullseye, but I appreciate guidance if anyone has
time.  Shared library version transitions trigger uncertainty in me.

I want to upload a new upstream libidn release into Debian, but upstream
has done a shared library transition.  Bullseye will ship with
libidn11-dev instead of libidn-dev too.  Is the first step on the
transition to provide a libidn-dev package experimental (and after the
release, unstable) and make all reverse build-dependencies use it?

If so, I plan to upload a new libidn version to experimental with this
libidn-dev package, and then start to file bugs to all build
reverse-dependencies to make them use libidn-dev.  Once all bugs have
been addressed, I can upload the new upstream version into unstable to
finish the transition.  Is that correct?  The reverse build dependencies
needs to be rebuilt against the new version though, and I'm not sure how
that happens.

I have prepared what I want to upload into experimental here:

https://salsa.debian.org/debian/libidn/-/tree/experimental

and I have attempted to re-build all reverse dependencies [1] here:

https://salsa.debian.org/debian/libidn/-/pipelines/255418

The failed tests looks harmless: echoping is FTFBS and broken for other
reasons, clickhouse just takes too long to build (but no indication of
problem), and systemd appear to failed for some other reason.

A 'git diff' between the version in bullseye and what I want to upload
to experimental is shown below, together with debdiff-output between the
built packages.

Generally, does things looks okay?  Specifically, what about the
Breaks/Replaces/Conflicts?  The d/changelog entry?  Will the confusing
'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
any problem?  Am I right to drop it here?

Should I wait post release with the upload to experimental, and/or
filing the bugs?

/Simon

[1] thanks to https://salsa.debian.org/bzed/reverse-dependency-ci

jas@latte:~/dpkg/libidn$ PAGER=cat git diff bullseye..experimental 
diff --git a/debian/changelog b/debian/changelog
index 28965c1..ebab7e8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+libidn (1.33-4) UNRELEASED; urgency=low
+
+  * Prepare for soname bump in newer upstream releases.
+- New libidn-dev package, contain what was in libidn11-dev before.
+- Make libidn11-dev a dummy transitional package.
+- Drop references to libidn9 and libidn9-dev, last seen in 2003
+  and didn't reach testing according to the tracker.
+  * For libidn11, drop confusing 'Replaces: libidn11-dev'.
+
+ -- Simon Josefsson   Sun, 16 May 2021 00:08:06 +0200
+
 libidn (1.33-3) unstable; urgency=low
 
   [ Simon Josefsson ]
diff --git a/debian/control b/debian/control
index b5996d7..65a58b6 100644
--- a/debian/control
+++ b/debian/control
@@ -26,10 +26,20 @@ Description: Command line and Emacs interface to GNU Libidn
  interface.
 
 Package: libidn11-dev
+Section: oldlibs
+Architecture: any
+Depends: libidn-dev, ${misc:Depends}
+Multi-Arch: same
+Description: Transitional development package for GNU Libidn
+ This is a transitional package.  It can safely be removed.
+
+Package: libidn-dev
 Section: libdevel
 Architecture: any
 Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
-Conflicts: libidn9-dev
+Breaks: libidn11-dev (<< 1.33-4)
+Replaces: libidn11-dev (<< 1.33-4)
+Provides: libidn11-dev
 Multi-Arch: same
 Description: Development files for GNU Libidn, an IDN library
  GNU Libidn is a fully documented implementation of the Stringprep,
@@ -43,8 +53,6 @@ Description: Development files for GNU Libidn, an IDN library
 Package: libidn11
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Conflicts: libidn9-dev
-Replaces: libidn11-dev
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
 Description: GNU Libidn library, implementation of IETF IDN specifications
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 5862fad..2861725 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 sign-tags = True
-debian-branch = bullseye
+debian-branch = experimental
diff --git a/debian/libidn11-dev.examples b/debian/libidn-dev.examples
similarity index 100%
rename from debian/libidn11-dev.examples
rename to debian/libidn-dev.examples
diff --git a/debian/libidn11-dev.info b/debian/libidn-dev.info
similarity index 100%
rename from debian/libidn11-dev.info
rename to debian/libidn-dev.info
diff --git a/debian/libidn11-dev.install b/debian/libidn-dev.install
similarity index 100%
rename from debian/libidn11-dev.install
rename to debian/libidn-dev.install
diff --git a/debian/libidn11-dev.manpages b/debian/libidn-dev.manpages
similarity index 100%
rename from debian/libidn11-dev.manpages
rename to debian/libidn-dev.manpages
diff --git a/debian/libidn11.symbols b/debian/libidn11.symbols
index a6f7a37..a5196d0 100644
--- a/debian/libidn11.symbols
+++ b/debian/libidn11.symbols
@@ -1,5 +1,5 @@
 libidn.so.11 libidn11 #MINV

Accepted oz 0.17.0-2 (source all) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 23 Aug 2019 05:42:17 +0200
Source: oz
Binary: oz
Architecture: source all
Version: 0.17.0-2
Distribution: unstable
Urgency: low
Maintainer: Simon Josefsson 
Changed-By: Simon Josefsson 
Description:
 oz - install virtual machine guest OSs with minimal input the user
Changes:
 oz (0.17.0-2) unstable; urgency=low
 .
   * Add autopkgtest.
   * Improve copyright (License is LGPL-2.1 not LGPL-2.1+).
   * Add lintian-overrides.
Checksums-Sha1:
 3e4e171432a00f7b46cb710af904aaff07ad46ef 1540 oz_0.17.0-2.dsc
 84c2f499e738008d69f5dd0bd20e3861a01ca8ad 3600 oz_0.17.0-2.debian.tar.xz
 3ecef20b7aea7fadc05d1c3b9fa7133f5517378a 91600 oz_0.17.0-2_all.deb
 ca049612d028075f3b592c676b97a7f11cf19194 5518 oz_0.17.0-2_amd64.buildinfo
Checksums-Sha256:
 dad4909a649770954a30587db9be4b52c457fb804138a9fc4b010d34b4eb8f98 1540 
oz_0.17.0-2.dsc
 528f20c1f455fdd01ce0191cf2c1e56a1c75f7491eb65f92ff469b534497a05f 3600 
oz_0.17.0-2.debian.tar.xz
 fea93c6cece1159a9d828c68dde09ceb993483930ed99a4baa4682943ed19901 91600 
oz_0.17.0-2_all.deb
 70ff9353aa791ba09b9024271341f780dd0960c3ea269d9992a58d14836a959b 5518 
oz_0.17.0-2_amd64.buildinfo
Files:
 337b34c1c8b8f8417b9dd106222b522a 1540 python optional oz_0.17.0-2.dsc
 40d87229180b9e557b62a80d4bd53819 3600 python optional oz_0.17.0-2.debian.tar.xz
 d0c487a82882bbddf2d8940a078671c3 91600 admin optional oz_0.17.0-2_all.deb
 a0de98c05e3fc7a1ae24dd95d3153799 5518 python optional 
oz_0.17.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl1ilH0UHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ2HEgf/eT9g1sWEOKYuIkpbtJch2U9pCEvD
AazgrGSkKTsSvgs7cD36jh3pJuucyW196gkDDLi8/sHpiwdv0WZZsFhLLzMkHp9L
LY9rb4EsMKPvxRDIR37/rI05f/PwBUqBILXyi6fIv0FyZMiVXbh0p7btkqONnWPH
OgEOVkP+KV39zRgpyWwdW5GPzPbrwlm7rHF255oTd+TuCZJA+dfNbjJP5+zjz7Wq
fIrxs3mng5dlVugV04hJbpY/TBxDbXUspLGpED1I8iwOTLsUrLlb63rjBJ/Pq3zH
DaBLGumZN9sMgG8tAjllOjWlEE+3qFWg/MR8GURch0osooxejR/a/z2jjw==
=WpAU
-END PGP SIGNATURE-

Accepted oz 0.17.0-1 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 15 Aug 2019 13:56:40 +0200
Source: oz
Architecture: source
Version: 0.17.0-1
Distribution: unstable
Urgency: low
Maintainer: Simon Josefsson 
Changed-By: Simon Josefsson 
Closes: 933509
Changes:
 oz (0.17.0-1) unstable; urgency=low
 .
   * New upstream version.
   * Standards-Version 4.4.0.
   * Compat 12.
   * Use dh-python and pybuild.
   * Use python 3.  Closes: #933509.
Checksums-Sha1:
 0b8721092ee2f0dbf7db408695dbc54f08c4a10c 1466 oz_0.17.0-1.dsc
 52ba9477d057cea93e222351f2a49958ae3bcb64 147539 oz_0.17.0.orig.tar.gz
 9ab1b948f7207a9ecdd8daef2943f0fb7f66d112 3048 oz_0.17.0-1.debian.tar.xz
 c06f033ea40b1953b9bb7467f8595170e3180e55 5518 oz_0.17.0-1_amd64.buildinfo
Checksums-Sha256:
 c12feb8a19af63cc7cfa9cecfbadc02de36e67b1e20ad9b40bb34047b0e219a2 1466 
oz_0.17.0-1.dsc
 948f95d6dcfdaea12bcbe6f76b1d43b4c17ea01a02cb4f9a754cc38743fd4dcb 147539 
oz_0.17.0.orig.tar.gz
 aa718375f2500631cf37eaed40253e5a292dead0faebd3487b76003c327dea38 3048 
oz_0.17.0-1.debian.tar.xz
 8d40c577ea20e28a11bc122026a774ad749b354a3e32c15a736e0082be8db00a 5518 
oz_0.17.0-1_amd64.buildinfo
Files:
 e3a1ffd0364d6503cf36f50573c89be0 1466 python optional oz_0.17.0-1.dsc
 16e5c533543d24ca3e1eb382c16a976b 147539 python optional oz_0.17.0.orig.tar.gz
 9676bc7a944818179cea81e017964744 3048 python optional oz_0.17.0-1.debian.tar.xz
 b6b4e9b86d87f65900b81c00bf0c8faf 5518 python optional 
oz_0.17.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl1VUaYUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ1PbQf/bxvq4Dh9TxuS8GwPYqPLqb1kWLKB
e3xJC9RW7VQkmSsSTqx/bJxwER5QrQoVENpaXxmnNabPdt196+oFJxaI0xE2Zdnp
dKJfZj7o+NDRMitwhx2z6RF3VLB/Q4PKE7sZMeVAherFvJGefMJWjcmIz4/ByLw+
zZQRnRZUthaNuBB6yogdMCh95yQTKhrbAKQvIJ+70vmOY2J3UNW0My43UXHKbdqj
dlYG5daGDvhKTvAwfi2ZcGEqENOypzh8N0nZ2KYD0BzsPZ36/x6My45LmxTNepaS
TuC1tDLEQv3ecVLv/Teb3CMcHxoV0BQ7KF9jUHYDB9eUBqZVoE+qghc34A==
=9pDZ
-END PGP SIGNATURE-

Accepted gss 1.0.3-4 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 08 Aug 2019 20:07:46 +0200
Source: gss
Architecture: source
Version: 1.0.3-4
Distribution: unstable
Urgency: low
Maintainer: Debian GSS Team 
Changed-By: Simon Josefsson 
Changes:
 gss (1.0.3-4) unstable; urgency=low
 .
   * Use https in watch file.
   * Update upstream-signing-key.pgp.
   * Standard-Versions 4.4.0.
   * Bump compat to 10 (not higher because of #885407).
 - Drop dh-autoreconf.
   * Update Vcs-Browser, Vcs-Git, and Homepage URLs.
   * Priority: optional instead of extra.
   * Use https in copyright file.
   * Update debian/README.source.
   * Enable hardening.
   * Drop gss-dbg package.
   * Multiarchify.
   * Update source/options.
   * Run self-check.
   * Use dpkg-gensymbols -c4.
   * Add Build-Depends-Package to symbol files.
Checksums-Sha1:
 6bb6221b3acc0e0fae048b71d48b6d281f21f686 1802 gss_1.0.3-4.dsc
 95004d1af12b123f4ba5bdc31ea47ddf83a78929 13500 gss_1.0.3-4.debian.tar.xz
 6224b4a506ddc058ddfe45e337d42461cd223874 9446 gss_1.0.3-4_amd64.buildinfo
Checksums-Sha256:
 e11035987c3ab22c1668c9ba33c96b7ca3c1f979aa7168a0a8a2b0dd171c08f8 1802 
gss_1.0.3-4.dsc
 713adca6e656cb8b3a1bdb2d799efeabb57c9628008b7e4b706e4e58b30352d3 13500 
gss_1.0.3-4.debian.tar.xz
 1afee8f0f90db94cc9db60eccc1115caabae58469a6ae7080dc25987272b862c 9446 
gss_1.0.3-4_amd64.buildinfo
Files:
 7667ac94d951b9a11d964dce8bd2b51b 1802 net optional gss_1.0.3-4.dsc
 47aa803107dfe78ec679a510a86405e8 13500 net optional gss_1.0.3-4.debian.tar.xz
 ee13f308e14368bef9567d1bcf7c6643 9446 net optional gss_1.0.3-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl1NPOAUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3wPQf/V22IM4xTLycQIdhCsyzNV3zYeqZs
4sS9Axx615ecQsCLOHROdGEG2B5RMlZUcJOGe4249EVcb/PISazzYILbAbCv9G4I
R78/eD9SOBNBu+CbSsZNRQDrFR02GBCsonFqNjBBaZTDh/Z7weTRNkHHCN0sM//T
/a+otP7jKEUJHAFmgbV3HrkNCtTvNW6CsfOXwXBG6AayNPaK1B+mAISn5/tJyAOb
8E//XlJ+A2kDEYlQjdn9YkvhcIs1RDT87p9blG9OzuKTk4Z3tXZOyYu+JLtHZ6rB
hoQmHOUiDtbfSKazv8jhQw5vffzMWQUEOB87Sr7Ba27Ssok+uauxidsrUg==
=No5y
-END PGP SIGNATURE-

Accepted gsasl 1.8.1-1 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 02 Aug 2019 15:15:01 +0200
Source: gsasl
Architecture: source
Version: 1.8.1-1
Distribution: unstable
Urgency: low
Maintainer: Debian XMPP Maintainers 
Changed-By: Simon Josefsson 
Closes: 838032 865164
Changes:
 gsasl (1.8.1-1) unstable; urgency=low
 .
   * New upstream stable release.
   * control, README.source: Update git URLs.
   * Standard-Versions 4.4.0.
   * Compat 10.
 - Drop dh-autoreconf and automake1.11 dependencies. Closes: #865164.
   * Add Build-Depends-Package to symbol files.
   * Enable hardening.
   * Use https in watch file.
   * Use https in copyright Format.
   * Use https in Homepage URL.
   * Priority: optional instead of extra.
   * Drop gsasl-dbg package.
   * Multiarchify the library packages, thanks Matthias Klose. Closes: #838032.
   * Update debian/upstream-signing-key.pgp.
   * Drop source/options.
   * Drop d/*.dirs files.
Checksums-Sha1:
 c01cbb3eb16d484240e6270bc26737ea9d0532c2 2146 gsasl_1.8.1-1.dsc
 82ba0079da6918784a8170d4a13ee133d9df1d7a 5774550 gsasl_1.8.1.orig.tar.gz
 62e425d1887890b74b05286be213830843660a89 228 gsasl_1.8.1.orig.tar.gz.asc
 e6c3cd67e2ecd26c0d9b17dc3a2f48f6fc9c1bd2 7588 gsasl_1.8.1-1.debian.tar.xz
 a4fd395cfc85daeab825fa7beda188ece5040955 7478 gsasl_1.8.1-1_amd64.buildinfo
Checksums-Sha256:
 0dff4b91888f8000cf0c7a987256dee68668634ee3f31708671385fcc99829f9 2146 
gsasl_1.8.1-1.dsc
 4dda162a511976bfef14ad1fecd7733719dfd9c361b5d09dc8414ea9d472d8d2 5774550 
gsasl_1.8.1.orig.tar.gz
 7ef6a3b12278057855eb62b7fa0c05bf296d398d407d05b721903bfe23c3b035 228 
gsasl_1.8.1.orig.tar.gz.asc
 1d80862c3550fccca4bacf2ba57a7ab581749b8520d364d92a2c3a53800d0c88 7588 
gsasl_1.8.1-1.debian.tar.xz
 2b3cbc5ee505324e1e91f0c9674879ee3c8771090a82a1a4da5e5950efbd54ac 7478 
gsasl_1.8.1-1_amd64.buildinfo
Files:
 10d520cf4530340c9384157a1a83221f 2146 devel optional gsasl_1.8.1-1.dsc
 624baa51e6ff53d2b2bbab005ea5190b 5774550 devel optional gsasl_1.8.1.orig.tar.gz
 b4074a8a9f371564f0d8ae0786a006ae 228 devel optional gsasl_1.8.1.orig.tar.gz.asc
 e395c4ee5132950a05504a5364304935 7588 devel optional 
gsasl_1.8.1-1.debian.tar.xz
 6725863f68c5774a7ce15c2b4ab20024 7478 devel optional 
gsasl_1.8.1-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl1ESNIUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3qtwgAuIml0323hbqBsIOfK0iQtvNFJvOg
ufdMKA1KcrlaHS2A7M5j3si95TJC5iDHqlkyAS+gN/avLrShVUmcHb8yHG45fAhq
sV63z9aqKBCXxQCDC0qH0fBbSjCzLPL4VHGii753BPL0foYFOruAnvz+WtCE7m0f
1DWPo3tnD4j9fB/ZDnT46bUavESedyBuT4NU5tf0NDqUplfBcGyMwFpmKcPobsTg
QQf3gzyRSWUiNL5KCjSBkSr7VTLw1ZyVohjdAdudZjVIMpV7J5oa5PhlVx8UbsKl
CvxYjOIhKnPi4yAa9TVJyVGAlYmhv3R1Ot9Y5qfuXdK4wglaOVaWPHFY/w==
=+n8U
-END PGP SIGNATURE-

Accepted shishi 1.0.2-7 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 23 Jul 2019 11:14:28 +0200
Source: shishi
Architecture: source
Version: 1.0.2-7
Distribution: unstable
Urgency: medium
Maintainer: Debian Shishi Team 
Changed-By: Simon Josefsson 
Changes:
 shishi (1.0.2-7) unstable; urgency=medium
 .
   * Acknowledge NMUs.
   * Bump compat to 10 (not higher because of #885407).
 - Drop dh-autoreconf.
   * Standards-Version 4.4.0.
   * Drop shishi-dbg package.
   * Priority: optional instead of extra.
   * Update Vcs-Browser, Vcs-Git, and Homepage URLs.
   * Use https in copyright Format.
   * Update upstream-signing-key.pgp.
   * Use https in watch file.
   * Add Build-Depends-Package to symbol files.
   * Drop obsolete shishi-kdc.postinst.
   * Enable hardening.
Checksums-Sha1:
 7ad65e70d8b55d5a3334a5d3fbf3015a8fbe4889 2212 shishi_1.0.2-7.dsc
 c9baf33e13714a1b4031e0ddc0b573f30624554b 25788 shishi_1.0.2-7.debian.tar.xz
 a090b7f5aee3c5d9bac5f5b806554d3fd941c33c 13026 shishi_1.0.2-7_amd64.buildinfo
Checksums-Sha256:
 2026085f87efc1c9d766b309debe9d2b576fecb2b38e043449bba97b7c899216 2212 
shishi_1.0.2-7.dsc
 938f4fcc8e2ea6bad979a0ad5a605b876e9f79fcabbdfb053dc395b3914274f7 25788 
shishi_1.0.2-7.debian.tar.xz
 cb9378a932792ae304b4e9d3ac8200f4f5e59d987cdae4f728f8b50c91904a9b 13026 
shishi_1.0.2-7_amd64.buildinfo
Files:
 65800a1691a751ccb29bccf282be594d 2212 net optional shishi_1.0.2-7.dsc
 e11ae3726feab2ce3d61f9a93cf5dc37 25788 net optional 
shishi_1.0.2-7.debian.tar.xz
 65a8b22217beb592611b3756ce9e6e66 13026 net optional 
shishi_1.0.2-7_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl04BvwUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3cFQf/cltaVy2S5/SQeHDH6TuwNbW0h5PA
wjbxEfgj7jtnt4W27jh9HlqzV4A8GFEYdNNMueataH/artWg6TfxzC47VxDidrrv
DhyDAf/NfjRiXjtS4SVSls0eV+2vTW62LA0rpeFmGEN+ycR9F3R5/j7U5Z+zVW4Y
PhJFjcdYtKQCMDnQl8/cEojD4ENWPk3R71uElwPcp1ynxXSpSNSoo1w443XwdBfy
tPaaJBD5qwDDVrLir+oQRHCYTluHvfM65Ta743La0KFPFnnsfMgUZhV5Tn5f06u5
leVMgyQBTAuLKtD0a/Qu1I+cknhp5Q68IDPM99Bvi4mNKT4KZobK8wXQZg==
=JwCs
-END PGP SIGNATURE-

Accepted libidn2 2.2.0-1 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 20 Jul 2019 22:35:12 +0200
Source: libidn2
Architecture: source
Version: 2.2.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Libidn team 
Changed-By: Simon Josefsson 
Closes: 882581 929879
Changes:
 libidn2 (2.2.0-1) unstable; urgency=medium
 .
   [ Simon Josefsson ]
   * New upstream version 2.2.0.
   * Update libidn2-0.symbols.
   * Standards-Version 4.4.0.
   * Compat 12.
 - Drop dh --fail-missing (now default).
 - Drop --parallel and --with autoreconf.
 - Drop Build-Depends on dh-autoreconf.
   * Add Build-Depends-Package to symbols file.
   * Drop help2man b-d.  Closes: #929879.
   * Ignore idn2.1 diff.
   * Make libidn2-doc Multi-Arch: foreign.
 .
   [ Ondřej Nový ]
   * d/copyright: Use https protocol in Format field
 .
   [ Bernhard Schmidt ]
   * Update and cleanup upstream signing keys.  Closes: #882581.
Checksums-Sha1:
 d9566247f126c904b76112a3bc85107b2515e4ec 2208 libidn2_2.2.0-1.dsc
 384e54e90f5d6ae54fb1e326bcb446045b4d3891 2110743 libidn2_2.2.0.orig.tar.gz
 eaf56b735b948346578ef4e6a6c2fb02b2fe9b8d 566 libidn2_2.2.0.orig.tar.gz.asc
 0081b3e3d9f755b77f162f97d679ab3458800c9a 10428 libidn2_2.2.0-1.debian.tar.xz
 cc8b6ddc5b703bf7519755fd6a89836c7227ba82 13018 libidn2_2.2.0-1_amd64.buildinfo
Checksums-Sha256:
 7d8532239f4ab0c0e246a20cb8997a3a8303843e32ae168e7f5f1e841bfc10fb 2208 
libidn2_2.2.0-1.dsc
 fc734732b506d878753ec6606982bf7b936e868c25c30ddb0d83f7d7056381fe 2110743 
libidn2_2.2.0.orig.tar.gz
 aa0a50999b8e6d9649476a61aa2041544c473f1eb059bf1bf197c502e98dfc2f 566 
libidn2_2.2.0.orig.tar.gz.asc
 6369fb8e9b874124a7d0f6c07dc30d086ddb6f1f91a98c33a832497d6281299d 10428 
libidn2_2.2.0-1.debian.tar.xz
 7ac6b7127a737c2ca01630af342ae041988ed7c2683ecc1a2a5b4683175c617f 13018 
libidn2_2.2.0-1_amd64.buildinfo
Files:
 d407913697265725811c694e402ca0fa 2208 libs optional libidn2_2.2.0-1.dsc
 b846d4d20e22b99d6f7387bb66e00a1f 2110743 libs optional 
libidn2_2.2.0.orig.tar.gz
 1e124cf75bc03dc1c43f6731027ea9c1 566 libs optional 
libidn2_2.2.0.orig.tar.gz.asc
 d452a54faccc7383f611f78fc8219514 10428 libs optional 
libidn2_2.2.0-1.debian.tar.xz
 73bafc9470c25dff25f9a286dc83b787 13018 libs optional 
libidn2_2.2.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl00HQwUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ0tGQf5AQJBLtredykav6GJDvWnLmcltYvz
hgLQRp1930oVNxXyvuXhILIGiPaq52Daf2mAMEsNnqR3b+VRvQ4I0zjGGiAYmHQ8
r8mpnQP3gPXZsuGxDooq4kW2t0UK6hCIDa1/GeRWyON52pTR4jM53cp/WiMx3fQs
tZlhSieRIS8k6bWSecC0tMK8pdCOzkOUQef/v7xBwcbCXn8z0RpHUT/7KxOzJUzw
v8NDw6UT74tJ7BfB8tqNE1Ay0oMNfztc/4r6h++uOACEnu4Buo9aD6oh8TPyqLmx
CudAHzrVKm1hyRL6rNvL7wrI0o7sKP+cA5e+F4jp7CvQIFfQKAiH+xS9Ww==
=Ay1A
-END PGP SIGNATURE-

Accepted libntlm 1.5-2 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 20 Jul 2019 20:57:31 +0200
Source: libntlm
Architecture: source
Version: 1.5-2
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Changes:
 libntlm (1.5-2) unstable; urgency=low
 .
   * Bump debhelper/compat from 11 to 12.
   * Update Standards-Version from 4.2.0 to 4.4.0.
   * Fix URL in README.source.
   * Update upstream-signing-key.pgp.
   * Add Build-Depends-Package to libntlm0.symbols.
Checksums-Sha1:
 b1bed6219388b3123ceb8d4856ae549d790a70ee 1927 libntlm_1.5-2.dsc
 f107d10bb50503b7a357ac7e03fb8f1741e548b9 9692 libntlm_1.5-2.debian.tar.xz
 64656d21f341af1730f7c0ff098c6c0461df44c3 5520 libntlm_1.5-2_amd64.buildinfo
Checksums-Sha256:
 6c983f1dbd46e2fda93822fba14ff847fb46f306dc30b78fae7643b23c7821b4 1927 
libntlm_1.5-2.dsc
 196565dc53c2b9116f3d5574ec16c2e3e8e07efd5757bb018616f43a8ff97974 9692 
libntlm_1.5-2.debian.tar.xz
 19c84b2ecfbf2d663581df79bf94f2a08b715956ce95817c7dcc38ef6435d503 5520 
libntlm_1.5-2_amd64.buildinfo
Files:
 1a98aa9a9750e0b8e7d58b5f9daf7364 1927 libs optional libntlm_1.5-2.dsc
 48bd20c505ccbf3a8c145e79fe04ab12 9692 libs optional libntlm_1.5-2.debian.tar.xz
 4c52a891205a714bbb25a327ef4481cc 5520 libs optional 
libntlm_1.5-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCgAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAl0zagQUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3NQAgAjc46TPHvcv+yIlpm1Gh61XfwE2Uu
iAvJh+k9GJAQE3RKOKUHbSjYAN7KqK+ZQ2IT2SWhsxn54ngvsVTQJNeh84zOxZBS
MTaZRNYM7jQaaP2pLYmIj6myWhl05+H3fvs/SDsNrBB3cwTXVeBdOaUedwNMoqyL
PonPGBU6kzZ9RuWVLNDhU9dNKqqLI+7zfSVehmkEyd95NkDp9n1sJWFz2+81t/YB
uwrKjU/zPQ+yZx1OEdEHWfX8m5a6XBXo7cVCq8Dquh2F3u/mVXRZYnZCpLhfqcJR
15CqrfXDxD1Bg0ReviswNcTslanUBcQ5eWhCFEFpf44vKnKrrNHbsKTYKA==
=5qPd
-END PGP SIGNATURE-

Accepted python-yubico 1.3.2-2 (source all) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 21 Mar 2019 17:33:09 +0100
Source: python-yubico
Binary: python-yubico python-yubico-tools
Architecture: source all
Version: 1.3.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 python-yubico - Python library for talking to Yubico YubiKeys
 python-yubico-tools - Tools for Yubico YubiKeys
Changes:
 python-yubico (1.3.2-2) unstable; urgency=medium
 .
   * Acknowledge NMU.
   * Move package from github to salsa, updating Vcs-* URLs.
Checksums-Sha1:
 00718015a8d391aa7a48018de6dd66e0bb328292 1891 python-yubico_1.3.2-2.dsc
 9943031d6158e904746cb23b472b4e3b6d905d41 7928 
python-yubico_1.3.2-2.debian.tar.xz
 66093a3f23c76d13eca54f8680c062cedd60286f 12304 
python-yubico-tools_1.3.2-2_all.deb
 6d2ddf29214047b8d145d8fb8c3bb4bd4b88e4a1 34848 python-yubico_1.3.2-2_all.deb
 84b2aafb9cce2ec75244d305727582d0951305d3 6117 
python-yubico_1.3.2-2_amd64.buildinfo
Checksums-Sha256:
 566748749ff3c936ed4d8fe9ebaa7831e8fa7cc4d40cac0c6362674e48b68ec5 1891 
python-yubico_1.3.2-2.dsc
 d0f0818b4212cde4b967f339c092e03f3e91fc4f826125c16f719f45893a6222 7928 
python-yubico_1.3.2-2.debian.tar.xz
 8eb9aa3a5ccf47a3f6114ecadf58616f8a88ca0142331038246d5eb731321db5 12304 
python-yubico-tools_1.3.2-2_all.deb
 b351c3411ade6516adfa3fcff34b6a926ed70568d2a195f21cc7990ff196f528 34848 
python-yubico_1.3.2-2_all.deb
 03c9aba5822751a7287c3376d34369a2a103c828a26789107dcb00fd096e2d83 6117 
python-yubico_1.3.2-2_amd64.buildinfo
Files:
 575172b92f79cffb7e37438a71ab41c0 1891 python optional python-yubico_1.3.2-2.dsc
 c39792b73fadef93e7b2f0a2334d5a03 7928 python optional 
python-yubico_1.3.2-2.debian.tar.xz
 786818b40cca4f8f87dc8ec75a6ff6f9 12304 utils optional 
python-yubico-tools_1.3.2-2_all.deb
 0413f4b518835c9b7d0b866cd46a06bc 34848 python optional 
python-yubico_1.3.2-2_all.deb
 e4a2763ea8163c4568db3f3de1356000 6117 python optional 
python-yubico_1.3.2-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlyTvhMUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3A1wf/TQiR5MKApOqjzKMWucCLyrNG8mmJ
COTRqk02pGpAiEwDdr9d2pT2nAxoXcAhZ4M//pjRo8DYtFPzoE5brj7NDP0CRzLn
wRIKOH5VQRIYxwSSzrmaTAg3VdyirtIw+RywAYOLtzRBC5E95i7Wmgpgg96HDJrF
eJjOCMKx8iZJbT0/N9Sj9YeMx7V1HQDKAaszaG3QfJKfB7CYMzUr6UzFfkqTGj+b
OYTZ4130HXgdxt6HI+wp5P2pTS4OQ0MmfJogAt2R471rSKJf/D2aAcJsLfBZXT9t
rZvEuXkDmrhwnN3+hEvBgVoh1M+7qird7NY/emSTF7cWUYCXILx7Xj/kKA==
=TFIQ
-END PGP SIGNATURE-

Accepted jabberd2 2.7.0-1 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 28 Jan 2019 22:29:15 +0100
Source: jabberd2
Binary: jabberd2 jabberd2-dbgsym
Architecture: source amd64
Version: 2.7.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian XMPP Maintainers 
Changed-By: Simon Josefsson 
Description:
 jabberd2   - Jabber instant messenger server
Closes: 857191 917758
Changes:
 jabberd2 (2.7.0-1) unstable; urgency=medium
 .
   * New upstream version.
 - Adapt pkgname.diff.
 - Drop patches/systemd-bindsto.diff (fixed upstream).  Closes: #857191.
 - Drop debian/patches/openssl11.diff (fixed upstream).
 - Fixes MySQL build problems.  Closes: #917758
   * Update Standards-Version from 4.1.3 to 4.3.0.
   * Rename tag in debian/source/lintian-overrides.
   * Drop trailing whitespace in debian/changelog.
   * Fix typo in debian/patches/man_hypen.diff.
   * Use https for Homepage: URL.
Checksums-Sha1:
 d32dfdaf49333c3e26b2caf06ebfa2098e275f1c 1774 jabberd2_2.7.0-1.dsc
 9200b9f22188caf603630d98d6f1c17c87a957b9 629992 jabberd2_2.7.0.orig.tar.gz
 236d96db04f4ff2ebdf65848fdec288f830e75d9 17200 jabberd2_2.7.0-1.debian.tar.xz
 f4961ae1ca021651aba103dee5dc2d30ff74f6a8 2133516 
jabberd2-dbgsym_2.7.0-1_amd64.deb
 c079831bb18ee4487f076be36d78805d120588bb 6754 jabberd2_2.7.0-1_amd64.buildinfo
 4c81ac7c24e6df3a5e1f8257eae8dc92a6049a50 388504 jabberd2_2.7.0-1_amd64.deb
Checksums-Sha256:
 fd856f208a95b6e9d52be1897afd48e6adc8a1f4062ff11b7bf303bfaa7787b5 1774 
jabberd2_2.7.0-1.dsc
 8ed7ae5952819d9e5bf1efb45735bfff3786b60144d9f60f8fe2788f552f1989 629992 
jabberd2_2.7.0.orig.tar.gz
 3218b920b9411ebb49986400b8b6f83fb7ae1f3a11626f32bb466593d76131b5 17200 
jabberd2_2.7.0-1.debian.tar.xz
 e08a1d0a7ba3852e07413baca6293e95bb331ff756fa098b0ec414bd3530f936 2133516 
jabberd2-dbgsym_2.7.0-1_amd64.deb
 01a82c7d080561482337835852db88c0511d5e098fb6acd2c6735a073911092a 6754 
jabberd2_2.7.0-1_amd64.buildinfo
 3e7d4d723fe2c13c1317b1f6905961be07812550d525fe893ede0faaeb3f693e 388504 
jabberd2_2.7.0-1_amd64.deb
Files:
 68bc56b2dc96c9bc0614ad48a62d8f91 1774 net optional jabberd2_2.7.0-1.dsc
 c2a01ab0c34b2d8f6a7e32f5cf6a2182 629992 net optional jabberd2_2.7.0.orig.tar.gz
 a6d94445adcc39ec755a2cf2f4438134 17200 net optional 
jabberd2_2.7.0-1.debian.tar.xz
 3679a0fd3d4728067f55d554ec9498d0 2133516 debug optional 
jabberd2-dbgsym_2.7.0-1_amd64.deb
 d1b680e5358999e2edcfdfa4643c156c 6754 net optional 
jabberd2_2.7.0-1_amd64.buildinfo
 1af4c54bcbbc8a7e593ef59be96f5bd7 388504 net optional jabberd2_2.7.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlxPezEUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ0TQQgAnzVCQy9tHn9mUQQKfRlY7WfJwC9K
ZG42wWEvv0Suc1Y3f5hfSsBqLWfEMY5G8FEoClEYMrD3mcFjpnSPL2hRpGK8KsaY
3cFszINnmZAnnIjjXRFEcDZqcSTDoMGtliLyEoxbf9q+10vfI8oYdXtQpIeQbNYt
aVys/fbC0EE35UNK9a5jnCumMgJHcT/kjUUgpcEPNAW32zG48iRVf4yiDWBnIdTi
txygNIcAhQO1HDaKGusOPc3aHP9R8GaIcbW3CAGe1uDmbwJTkv60S9qI0WtDzIT3
yCMT8rQWMF8QFOGkPnMoDdaB1Ph3Lf/3KBxHmeOGJGM7zUYXjunfBdKAOA==
=sH0M
-END PGP SIGNATURE-

Accepted python-pyhsm 1.2.1-1 (source all) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 26 Sep 2018 12:43:09 +0200
Source: python-pyhsm
Binary: python-pyhsm yhsm-tools yhsm-validation-server yhsm-yubikey-ksm 
yhsm-daemon
Architecture: source all
Version: 1.2.1-1
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 python-pyhsm - Python code for talking to a Yubico YubiHSM hardware
 yhsm-daemon - YubiHSM server daemon
 yhsm-tools - Common files for YubiHSM applications
 yhsm-validation-server - Validation server using YubiHSM
 yhsm-yubikey-ksm - Yubikey Key Storage Module using YubiHSM
Changes:
 python-pyhsm (1.2.1-1) unstable; urgency=low
 .
   [ Jean Paul Galea ]
   * New upstream release.
 .
   [ Simon Josefsson ]
   * Update Standards-Version from 3.9.8 to 4.2.1.
   * Use https URL in copyright file.
   * Bump debhelper/compat from 9 to 11.
   * Move packaging to Salsa, fix Vcs-Browser/Vcs-Git/README.source URLs.
   * Add pyhsm.egg-info/PKG-INFO to debian/source/options extend-diff.
Checksums-Sha1:
 1cc330c3110af581f012bf733ec0f3b8874a56d3 2260 python-pyhsm_1.2.1-1.dsc
 d9236ef6d2cdc52e7f798ce38cfbbab85a57f016 100911 python-pyhsm_1.2.1.orig.tar.gz
 df421a4fbb622e947955b93da7f64fe86327c1fa 287 python-pyhsm_1.2.1.orig.tar.gz.asc
 7bf69c446d0729b33df518e765d525a0ec5975bb 64836 
python-pyhsm_1.2.1-1.debian.tar.xz
 f52fc1d39f241cebbef0048a34d6d9b07a879761 45288 python-pyhsm_1.2.1-1_all.deb
 faa3afad33baf74f195703827407651a519c38b9 6839 
python-pyhsm_1.2.1-1_amd64.buildinfo
 ab70714a82381de42ef74ec4080933834a7288d5 22292 yhsm-daemon_1.2.1-1_all.deb
 6ace62d99e96f0e020bb0e84b4c0d4ca7baf990a 29572 yhsm-tools_1.2.1-1_all.deb
 e7cff0d34786d6b2d8b88876f30b17d865e0dfd8 34688 
yhsm-validation-server_1.2.1-1_all.deb
 9675f66fd24f1a8663beb60b67cfe3bb78c42f07 34176 yhsm-yubikey-ksm_1.2.1-1_all.deb
Checksums-Sha256:
 da28343a2e912775289b2dcd2dc1c2776729289ccde5a9c48b567981893693a4 2260 
python-pyhsm_1.2.1-1.dsc
 ca7225e5b59e8bd1c54c4345a4f60206c37bb52ff1d2b55c422fdc3fab352b30 100911 
python-pyhsm_1.2.1.orig.tar.gz
 6bff38d7287297bcd91627cca83386ca00c796fc58366b9635fec137f312dcd8 287 
python-pyhsm_1.2.1.orig.tar.gz.asc
 1bced840b5746e1cfd4c7cda68c38a7a4e90c84ad172a0cf8c72107cc4dc9098 64836 
python-pyhsm_1.2.1-1.debian.tar.xz
 f5d56a2a038e9b1e076ef5584ab57f92fa6ce5252b4ab8f696c3ff092c76b4d1 45288 
python-pyhsm_1.2.1-1_all.deb
 99a9bef3b74b4d6503bfe1ffb04e8e99afea844d225c8f7c7a6c1974aa57a428 6839 
python-pyhsm_1.2.1-1_amd64.buildinfo
 16bd3b5bef0618a1fbffba8bad9b9a9b24173accfcc5067d01a49f00a439ef85 22292 
yhsm-daemon_1.2.1-1_all.deb
 49e425cdaaf9cc2a160302202ca86cc118d02abb623026ffb0a9ab7e9e4e1568 29572 
yhsm-tools_1.2.1-1_all.deb
 70f50822cc259f0ccb0c18a52980a1a53e27e9c0f70c5445578fc222c19b9439 34688 
yhsm-validation-server_1.2.1-1_all.deb
 7dceda3130388edceae95375e75a7d11af565dca43e6d2ab686f9680e871c467 34176 
yhsm-yubikey-ksm_1.2.1-1_all.deb
Files:
 2e2a06c203979b10782bcd29b1c95e62 2260 python optional python-pyhsm_1.2.1-1.dsc
 a375cb714413f32d2fa350a7858ab50a 100911 python optional 
python-pyhsm_1.2.1.orig.tar.gz
 ef645e344fb5681ff97e2e1152298054 287 python optional 
python-pyhsm_1.2.1.orig.tar.gz.asc
 f5b9bfd0715361fb7b9040b6fd977da4 64836 python optional 
python-pyhsm_1.2.1-1.debian.tar.xz
 67e6e79ef4e22d6df817b09358769489 45288 python optional 
python-pyhsm_1.2.1-1_all.deb
 99cb46fb466906945abbef28957d862e 6839 python optional 
python-pyhsm_1.2.1-1_amd64.buildinfo
 c57ee5f7bf9a2dc007fe5b5b4c0c8774 22292 net optional yhsm-daemon_1.2.1-1_all.deb
 e81d23b48dc7f47219542b62ea67e63d 29572 utils optional 
yhsm-tools_1.2.1-1_all.deb
 ce53745229c204f8d6740839daa919f1 34688 net optional 
yhsm-validation-server_1.2.1-1_all.deb
 c22d0e3e6c872d609d3a4f4c1b3e6980 34176 net optional 
yhsm-yubikey-ksm_1.2.1-1_all.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlurZtYUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ0nPAf8DYNmCTkSOYROO6AOXp+nI7XedRMx
FWTPyu+Y9iA8iLhkmKsausl800xfwJc+Aiz12IzNJsCPdAChwG5Vx3GvEEp8sWzD
RG/F++PPQTbyBITn3U1IEYg/44mckdG5Sz6GQjXRE/79aoO6WuIDD82pPwcvhkaV
9dMifPbNafyjUKvoSxZV5T6i79e6MTBi7wQ4jOziYGzIji/6Fazng6WSrgKPN260
9dNeV7wcLR910+vdFuxwWGdLyxgEIh5DdWL8yEUjiBmkBCMrE5Ch7Gj82x499ryr
9zmF+Vrijn3DUrXJW09b2kPRnwQ3N8WUp6LpXub97yBapW39KJiV5Lyvgg==
=Iufn
-END PGP SIGNATURE-

Accepted yubikey-piv-manager 1.4.2-2 (source all) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 26 Sep 2018 12:11:01 +0200
Source: yubikey-piv-manager
Binary: yubikey-piv-manager
Architecture: source all
Version: 1.4.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 yubikey-piv-manager - Graphical tool for managing your PIV-enabled YubiKey
Changes:
 yubikey-piv-manager (1.4.2-2) unstable; urgency=medium
 .
   * Update Standards-Version from 3.9.8 to 4.2.1.
   * Move packaging to Salsa, fix Vcs-Browser/Vcs-Git/README.source URLs.
   * Use https URL in copyright file.
   * Bump debhelper/compat from 9 to 11.
   * Drop unnecessary X-Python-Version: >= 2.7.
   * Silence lintian warning on fix-pyside.diff file.
Checksums-Sha1:
 a415d81f2e659a85c34910e5ec27b34e88bdb775 1904 yubikey-piv-manager_1.4.2-2.dsc
 3debc83ce9aeafb047b57733d4a73da4cb2db424 24756 
yubikey-piv-manager_1.4.2-2.debian.tar.xz
 9d48a5d81a4d9942d0db7059280abff56595f8c1 52712 
yubikey-piv-manager_1.4.2-2_all.deb
 1088427b67cc70a32a812f9595d23c7408424e65 5866 
yubikey-piv-manager_1.4.2-2_amd64.buildinfo
Checksums-Sha256:
 e6c9237f8c6b693a8afb5249167460a2e6dfe6c688482174a9a1babbb2b8206e 1904 
yubikey-piv-manager_1.4.2-2.dsc
 def127417043c8daddf1e876a4c25400f9e495b7cb255da4401db1327606c1f2 24756 
yubikey-piv-manager_1.4.2-2.debian.tar.xz
 8da61fc44eb25f40eb5a1e89ac82b9c232bdb6ef75082860df07225f097035bd 52712 
yubikey-piv-manager_1.4.2-2_all.deb
 279c365e1bf481065e83b307b1b4321cd5dfdac2bdc45c1007ec1626042237e7 5866 
yubikey-piv-manager_1.4.2-2_amd64.buildinfo
Files:
 ac621a9fe0792e09d9b764a9a0634eb3 1904 utils optional 
yubikey-piv-manager_1.4.2-2.dsc
 9c9bbf386179d0820ced075742983d32 24756 utils optional 
yubikey-piv-manager_1.4.2-2.debian.tar.xz
 7dacd95431cb5b5b3c0c2b842cc66fa3 52712 utils optional 
yubikey-piv-manager_1.4.2-2_all.deb
 b8fc80d46730e9dcc11df17ce9b7edaa 5866 utils optional 
yubikey-piv-manager_1.4.2-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlurXgkUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ01fQf/bJJNDcDkhgWu7Gkgl+TRsK7F11pj
9ANwayxXAXkUlBm3E9ngpKJlXpHTpw4EwiXpNK/TBGI2VRKhpPJy9sItJ5gZKTmg
8fXBfJ5zsRFTvNLC0cc1Muq6NeUWwT+ytXm2MSDXsy9KzLg/gC9Rgr77QACVl51c
V5DpsasaQLCc/69qy6wvsDVoKBhuop8dS4DiI++keaGVjlU217VTIv3Y0nbqHjn8
pFGWyO6Y9AjtPBL3+qhdfob3rYEehtQv48YJZJAN2Q/Uqdo+1TQ9jSHL6xdoxt/5
EnYizRlDgdFbVsqZ1/nULID6aK69k8w12pzlgARltxFFuN5Gu2lea69wNA==
=Fv5u
-END PGP SIGNATURE-

Accepted ykclient 2.15-2 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 26 Sep 2018 11:34:05 +0200
Source: ykclient
Binary: libykclient3 libykclient-dev
Architecture: source amd64
Version: 2.15-2
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 libykclient-dev - Yubikey client library development files
 libykclient3 - Yubikey client library runtime
Changes:
 ykclient (2.15-2) unstable; urgency=low
 .
   * Update Standards-Version from 3.9.8 to 4.2.1.
   * Move packaging to Salsa, fix Vcs-Browser/Vcs-Git/README.source URLs.
   * Use https URL in copyright file.
   * Bump debhelper/compat from 9 to 11.
 - Drop --parallel and --with autoreconf.
 - Drop Build-Depends on autotools-dev and dh-autoreconf.
   * Change maintainer to pkg-auth-maintainers.
   * Drop unnecessary debian/libykclient3.dirs
 and debian/libykclient-dev.dirs.
Checksums-Sha1:
 066dd534c124e2d30041a02dadd4b573dc628f87 1858 ykclient_2.15-2.dsc
 36f2bf9d93ba3c3660b1c7fca544bc70e34dafd7 22800 ykclient_2.15-2.debian.tar.xz
 6c27df89a9390b703c943df8a4edc553ec98fe36 8188 
libykclient-dev-dbgsym_2.15-2_amd64.deb
 99efad754be743fa30a6c8f7c2717bf9243d0ff8 35712 libykclient-dev_2.15-2_amd64.deb
 66254638ace7f31fd6570404b47a1227cf3c2181 46488 
libykclient3-dbgsym_2.15-2_amd64.deb
 25666167577ab7ca38e738a17320893251b85140 32196 libykclient3_2.15-2_amd64.deb
 c3d38d605ae6680519740540c67ad8211a4ebf02 6820 ykclient_2.15-2_amd64.buildinfo
Checksums-Sha256:
 d33a25e5f6ee84c3c0b44e8e836c830174836d507a6caccb00cc250c588b44a6 1858 
ykclient_2.15-2.dsc
 afe3aedb2ceee086dc2355486df2113810102c7cd70fdfef0a2efbe73f86c7c3 22800 
ykclient_2.15-2.debian.tar.xz
 b63dd92e0f0d12536f2486e83d6c90e03a40027191be8af98a121d505ef2254a 8188 
libykclient-dev-dbgsym_2.15-2_amd64.deb
 065ddf5f3f9c09a70cc015a503c57e37075c3bf5019299e13e2261e614e06835 35712 
libykclient-dev_2.15-2_amd64.deb
 c7b0163682904f006e8791317b6235715aa4e51d70504df99a4bb87c75af7252 46488 
libykclient3-dbgsym_2.15-2_amd64.deb
 5d7f1218d9c205eed7fd0223eeadb57bd4e2cae0e2ef0d70d232bbbf916c9b66 32196 
libykclient3_2.15-2_amd64.deb
 36aceee8a9ebe7c713d378a63f6e13127974d400a3cdab0d7eee44c008d6a4ee 6820 
ykclient_2.15-2_amd64.buildinfo
Files:
 13d774bd3f3410da48bcc4ebc7f4b715 1858 libs optional ykclient_2.15-2.dsc
 b472314e403aab948499af0a669c721c 22800 libs optional 
ykclient_2.15-2.debian.tar.xz
 5962befd522902b9063b0c1eb41c5e8f 8188 debug optional 
libykclient-dev-dbgsym_2.15-2_amd64.deb
 1dbbddd8d764e843120ddbacc034e196 35712 libdevel optional 
libykclient-dev_2.15-2_amd64.deb
 9ba6dc81779acc5b76da92eedb6a3c90 46488 debug optional 
libykclient3-dbgsym_2.15-2_amd64.deb
 2e2fc84dbf88f2bb9339216e0cb79e5c 32196 libs optional 
libykclient3_2.15-2_amd64.deb
 95eb88449c70cc3ea4acd3340a5b7b37 6820 libs optional 
ykclient_2.15-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlurVUsUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ2S3Qf/dC3eYBMVBMI0ZSpadoWVbXS/M0Qc
xcsB4vZQZRDj9c99IC6CCQDKE6+/gIboznjVQjZIAtqjl8EZ/bWyY3U0m3YpMopS
dzf4aro2x1hC1gIdsAR1JDNtzt92Jh2oWrKqFYZonSDEx1n6Vgpi05Ghz+P9NHrL
XaCRoqdT4y8FA5t9zCZ0Jg7mL0lc0v05l1z4oJWimwoycKIU3GqJv1VdcmOk2jFF
FUJ6cPxUTS5mqS6uS9bIo053ViOexwkhLUcV1NnJ+Q6XWxjVowu1y1VFF86x/oZ3
TcicxqMOtUXA9vyFnZAerHlYQd2LDyHEuTEK6bCteaCQf0lBWXKoF9xHvQ==
=I4oG
-END PGP SIGNATURE-

Accepted yubico-piv-tool 1.6.2-1 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 25 Sep 2018 11:40:12 +0200
Source: yubico-piv-tool
Binary: libykpiv1 libykpiv-dev yubico-piv-tool ykcs11
Architecture: source amd64
Version: 1.6.2-1
Distribution: unstable
Urgency: high
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 libykpiv-dev - Development files for the YubiKey PIV Library
 libykpiv1  - Library for communication with the YubiKey PIV smartcard
 ykcs11 - PKCS#11 module for the YubiKey PIV applet
 yubico-piv-tool - Command line tool for the YubiKey PIV applet
Changes:
 yubico-piv-tool (1.6.2-1) unstable; urgency=high
 .
   * New upstream version 1.6.2.
   * Update Standards-Version from 4.2.0 to 4.2.1.
Checksums-Sha1:
 e7e279b06018fea82274800b6c0d1912f4e0472e 2077 yubico-piv-tool_1.6.2-1.dsc
 b25c4028574042a443f7851bd6eb687a5eb1e3b7 584063 
yubico-piv-tool_1.6.2.orig.tar.gz
 22e41df1eef8a329db6f0bf15a67c8390bebe563 51248 
yubico-piv-tool_1.6.2-1.debian.tar.xz
 7f61a8ec94fa05edf2343fb15c816bd16d0723f6 58676 libykpiv-dev_1.6.2-1_amd64.deb
 3715b88b6461562f6e3b5f916bda19f17e76cc60 64652 
libykpiv1-dbgsym_1.6.2-1_amd64.deb
 d23ab23f20e16da9f5a1eb5dd9cbee2de3249cb7 53764 libykpiv1_1.6.2-1_amd64.deb
 b4e0412913ec80ec649d6f21b26364dfa505fc22 82628 ykcs11-dbgsym_1.6.2-1_amd64.deb
 b9f0953d82c887cb3351a72f31cca46d76d969b8 55652 ykcs11_1.6.2-1_amd64.deb
 aa76e09faac1a369d191e3f73c5779e88c8a3cf1 78996 
yubico-piv-tool-dbgsym_1.6.2-1_amd64.deb
 e0f0ea82fe88075661e97c682cabe6669ce7f394 7164 
yubico-piv-tool_1.6.2-1_amd64.buildinfo
 abc58e2cf925fdee40c8d2a00388e7c89dba862a 59180 
yubico-piv-tool_1.6.2-1_amd64.deb
Checksums-Sha256:
 b2b35fb9c683cb8b53a7325c017cd38ce6764de9c3ca8fcaba0e8d081f6ac22b 2077 
yubico-piv-tool_1.6.2-1.dsc
 ea61bcd5c75471ed21903967d0121fb090aa4d325ec279a24633e3235fdf231b 584063 
yubico-piv-tool_1.6.2.orig.tar.gz
 5439c8e65566715f35cbae1856105f2e1b9ec9001b8786fed255c308b4aeb6fe 51248 
yubico-piv-tool_1.6.2-1.debian.tar.xz
 fa855d514cd12c3bb313aacf54fe646dccf6de8ffdc262b750a0be4f7dd70c89 58676 
libykpiv-dev_1.6.2-1_amd64.deb
 e8e06921ba9ac78095ef1c6f4b6a6c9bbd64498e57bf9116b964e46dc64f15e7 64652 
libykpiv1-dbgsym_1.6.2-1_amd64.deb
 968cdc02ad53008d1380b01c5ce4ae4024cd6df849c49ba47f9b586bad188d34 53764 
libykpiv1_1.6.2-1_amd64.deb
 fc990539350e16fb6c3fefa0c473ab366a1e7fd3823ec5cbc85c38041a45417d 82628 
ykcs11-dbgsym_1.6.2-1_amd64.deb
 f98a1158479898b8bf72a29d6c4b1b9ecaf7226140b6eed837008942c5611b6e 55652 
ykcs11_1.6.2-1_amd64.deb
 ba485dbdb80b8073dffa461e70b0ec0c36242b58430b88278e998266ab7b3ac9 78996 
yubico-piv-tool-dbgsym_1.6.2-1_amd64.deb
 f6e4e62464976f9e1f54ca5dfc291776b58b1c81ce9e74eef386414be4e316dd 7164 
yubico-piv-tool_1.6.2-1_amd64.buildinfo
 70a0e3f37812507b6dc0431564661154f725dce9fc455a0bb8ed1abb5c94b3ac 59180 
yubico-piv-tool_1.6.2-1_amd64.deb
Files:
 a7f583298ed04638dbabd0d7140fbba2 2077 utils optional 
yubico-piv-tool_1.6.2-1.dsc
 5884f367eb078685240a77f3b53bcba4 584063 utils optional 
yubico-piv-tool_1.6.2.orig.tar.gz
 4b16a146765fa37768cd9167f33ab3fc 51248 utils optional 
yubico-piv-tool_1.6.2-1.debian.tar.xz
 1020b8421d2649282e39c3049c8d2d76 58676 libdevel optional 
libykpiv-dev_1.6.2-1_amd64.deb
 c9f827677df0d87e129cdd89f7620ca7 64652 debug optional 
libykpiv1-dbgsym_1.6.2-1_amd64.deb
 80f471889c532aeea51eaa9ba0a0f02a 53764 libs optional 
libykpiv1_1.6.2-1_amd64.deb
 af93fc2e0aabc7587d3312712606d7a9 82628 debug optional 
ykcs11-dbgsym_1.6.2-1_amd64.deb
 5556148a1e13260e5a9693e6773528bc 55652 libs optional ykcs11_1.6.2-1_amd64.deb
 d87fa23bfdbb0b1c7c05b324adecbdaa 78996 debug optional 
yubico-piv-tool-dbgsym_1.6.2-1_amd64.deb
 27d6ccb26129374a9a4e50f33737e03c 7164 utils optional 
yubico-piv-tool_1.6.2-1_amd64.buildinfo
 ce6d3abda6490e7d8d7ffec76d1af3de 59180 utils optional 
yubico-piv-tool_1.6.2-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAluqCSoUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ16gAf+Ny5QHfs6hN7Aqdo2f+DfhlzEYDyG
eftrjxktD82EDreOj5AvCM85c8osBR1oZs+Y1yAjZkrDvGkroDla10tpeVFEqfJf
NTjmpbajJZhXQfz0MuopuGlsE+fnW2DHq3qXdoeOvtNndCzZx/jWciVbV8Z550kP
qQKwckfHDteFz/95uPY2Igo2dd7xqMA6/VzeXwkCi9yb90qTwWK3sWPKkNMNdQDN
iIRBEXisD6FC9vSWTK8ZvnrTKTnTX+JCmaDKZhMeLjQQG8KsMA6OQpzZ6Rm+DCp6
gcnG8LUbECeuh+7AUJlkFChsiVAOyhqV+dJ23KV1OzmM7/Ux8Sht5ApAGA==
=OIRB
-END PGP SIGNATURE-

Accepted oz 0.16.0-2 (source all) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 24 Sep 2018 15:17:57 +0200
Source: oz
Binary: oz
Architecture: source all
Version: 0.16.0-2
Distribution: unstable
Urgency: low
Maintainer: Simon Josefsson 
Changed-By: Simon Josefsson 
Description:
 oz - install virtual machine guest OSs with minimal input the user
Closes: 907255
Changes:
 oz (0.16.0-2) unstable; urgency=low
 .
   * Update Standards-Version from 4.0.0 to 4.2.1.
   * Change debhelper/compat from 9 to 11.
   * Packaging moved to Salsa, update Vcs-Browser and Vcs-Git.
   * Use https copyright/Homepage URL.
   * Put tools in Section: admin.
   * Drop unnecessary X-Python-Version: >= 2.6.
   * Re-add python-monotonic and python-requests deps.  Closes: #907255.
Checksums-Sha1:
 71f22ae332dc3b397aa275fed7334983c07e5565 1467 oz_0.16.0-2.dsc
 7bdbec59abffc16bd4e52d30c45a3c16dd80d01f 3004 oz_0.16.0-2.debian.tar.xz
 748cdfad6284b1875db4aa3001549979f097bcdf 88532 oz_0.16.0-2_all.deb
 221528e83511a2316c467a6f97987ea2b4eee10d 5630 oz_0.16.0-2_amd64.buildinfo
Checksums-Sha256:
 ae2e2f54391a287da5b8d808acf385a238e623b73e49102e27f3dd3085dd14e2 1467 
oz_0.16.0-2.dsc
 f88755743faf9d953334c1ac65c9186429effe33722eb30e691fa8d0fe3b0e6b 3004 
oz_0.16.0-2.debian.tar.xz
 b73404197b53c6427431ad1ba34f839cd90fcd2f339f0572fb3cd82dfb49b2c4 88532 
oz_0.16.0-2_all.deb
 d9d090cefe279aaeeeafb0fb404356f9f55bb0ce07cc946f7902b88eb3be4b09 5630 
oz_0.16.0-2_amd64.buildinfo
Files:
 a10442a294e5b46800a6faad38c15820 1467 python optional oz_0.16.0-2.dsc
 00ddd2973529ab6222b117af760d28c5 3004 python optional oz_0.16.0-2.debian.tar.xz
 fb3e679ce96f8610019a71021b997ed9 88532 admin optional oz_0.16.0-2_all.deb
 be7b86b4f8344a84e183dafc07348d89 5630 python optional 
oz_0.16.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAluo7AsUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ1zlQgAodf3VaO5NyRN0hhc6hg84q5eogdr
2ahTBFUzyBOE5+aSgEEVgCDbk3Xq8LCu+WOOoM1bz/op8ZnGiF8NJC5+thb4dOvo
vHB1ykI8R7om3yqaEMOyKaO/brN9ACJyPVR1dfw1Ke7E4R68lTiRzTLFuYMsf/wC
ndhMG1cfRhGrY2evyOMwg/U4IHi/ctyrJztgM0B9TCWHcP5NsTx1zJqV0nhO5q3k
iZ+AGBa8Cv9SheGrUUUNuafQYVNKJH9HSnqGS1KcBZRPcjt3NtP2J46F54xF/pZH
TaKvGISQTQoUvfJyBdA9I6cXCyz4m/xcB8Ll+fNEN3lD3v6GVJ5hYchAYQ==
=ReaI
-END PGP SIGNATURE-

Accepted libntlm 1.5-1 (source) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 24 Aug 2018 22:03:11 +0200
Source: libntlm
Binary: libntlm0-dev libntlm0
Architecture: source
Version: 1.5-1
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 libntlm0   - NTLM authentication library
 libntlm0-dev - Development files for the NTLM authentication library
Changes:
 libntlm (1.5-1) unstable; urgency=low
 .
   * New upstream version.
   * Bump debhelper/compat from 9 to 11.
 - Drop --parallel and --with autoreconf.
 - Drop Build-Depends on dh-autoreconf.
   * Update Standards-Version from 3.9.8 to 4.2.0.
   * Reflect move to salsa in Vcs-* URLs.
   * Change maintainer to pkg-auth-maintainers instead of pkg-xmpp-devel.
   * Update copyright file (no license changes).
   * Use https watch URI.
   * Make libntlm0-dev Multi-Arch: same.
Checksums-Sha1:
 a5079b25de16ebd823db5399fbce6b64922bdfef 1930 libntlm_1.5-1.dsc
 eaecb15173d41381862920cb78238c695b41f43a 658935 libntlm_1.5.orig.tar.gz
 ba88921631254e248ded28c9ee3d8dbc0f48303d 310 libntlm_1.5.orig.tar.gz.asc
 1e5e119c640a054118f65248ca654816d37a3e1c 60372 libntlm_1.5-1.debian.tar.xz
 a2aad2c39885be31b41196ebaf14bb5efc285062 5706 libntlm_1.5-1_amd64.buildinfo
Checksums-Sha256:
 47e460b47a49b94d58fbda305a187a052f7aa371bfed568203bf186cb13349f0 1930 
libntlm_1.5-1.dsc
 53d799f696a93b01fe877ccdef2326ed990c0b9f66e380bceaf7bd9cdcd99bbd 658935 
libntlm_1.5.orig.tar.gz
 d5e65317fb177de9a87281215c1920966c636cf9cee4c2c117d65fcb2c4a667c 310 
libntlm_1.5.orig.tar.gz.asc
 9abeb2b77007a642e0c165a29d62140928cdf6d359e9f4c7e301ba3c4e299f0d 60372 
libntlm_1.5-1.debian.tar.xz
 7b73068b92332d94e248e1d7481374dba3620d9ef4c5eb93d2816498850a4d31 5706 
libntlm_1.5-1_amd64.buildinfo
Files:
 d3a796540d0f461cf152ba26429ca8d4 1930 libs optional libntlm_1.5-1.dsc
 375a3a87d29b61da5466f9b06325ad62 658935 libs optional libntlm_1.5.orig.tar.gz
 7c9b492e92df1b230e944e151131a50f 310 libs optional libntlm_1.5.orig.tar.gz.asc
 f104dd9b08e0ac9090a7d69b63d706e4 60372 libs optional 
libntlm_1.5-1.debian.tar.xz
 8cebc7b27f30bc571cb7084be3a836fe 5706 libs optional 
libntlm_1.5-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAluAcF8UHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ19mgf9E1JfD5HLcBbRWyp9NbzwP5kQivsB
6qaCp40jnAP7CycZUWjXC/6WNhZhBXeVLYHIdB9dmdxybQLMe/uA5BTzwXEpRMWD
FwF2nFs3POczR3uXfsBgDrpgFlz4gjeQPc/AP1qYiQotUNsA3AlzMHsz4xc3VffL
AcYNoI/IwbqjNZAydiHY5pqJBdddicoZZCf/bHimSScsvPoJ3vATKnJhxnlsuq/0
ZXcsUGeBTaqV24/kRmzqevZgsGEu2QUCFD8UKlXay2v2oTQ1gEOGzSuJDtQoZwIa
EnTXwgXBCu3JIodMgqx8h8KYbe8NbapBIVxIh7nuFEAWLB0oirHaXXnp0A==
=bdvB
-END PGP SIGNATURE-

Accepted yubico-pam 2.26-1 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 04 Aug 2018 08:50:40 +0200
Source: yubico-pam
Binary: libpam-yubico
Architecture: source amd64
Version: 2.26-1
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 libpam-yubico - two-factor password and YubiKey OTP PAM module
Changes:
 yubico-pam (2.26-1) unstable; urgency=low
 .
   * New upstream version.
   * Update Standards-Version from 3.9.8 to 4.1.5.
   * Use https URL in copyright file (lintian insecure-copyright-format-uri).
   * Use debhelper compat 11.
 - Drop dh-autoreconf and autotools-dev source-dependency.
 - Drop --parallel and --with autoreconf.
 - Drop --disable-silent-rules.
   * Update VCS-* headers to point at Salsa repository rather than GitHub.
Checksums-Sha1:
 ed16ec25bbc7a2310d4b67372b1a6541d052cd68 1864 yubico-pam_2.26-1.dsc
 5bb66205af15f6913010659c8c3b7f3391576905 423451 yubico-pam_2.26.orig.tar.gz
 198ae375d9eade8636abd96bfd09c5779146993b 69540 yubico-pam_2.26-1.debian.tar.xz
 88f1e32e985b18876e88e97b47d371632f7089c4 75988 
libpam-yubico-dbgsym_2.26-1_amd64.deb
 5352dcc1d2a913997344f2d6ab471ce11ab5c838 88900 libpam-yubico_2.26-1_amd64.deb
 8e35bccec907c571f51699c8e563722ffb346fa5 6585 yubico-pam_2.26-1_amd64.buildinfo
Checksums-Sha256:
 e5e918cc258b61e6f140feb8690a2fb85a18b4b275870423d00879f0bcc7e394 1864 
yubico-pam_2.26-1.dsc
 2de96495963fefd72b98243952ca5d5ec513e702c596e54bc667ef6b5e252966 423451 
yubico-pam_2.26.orig.tar.gz
 27d61c2f6e3490a6579e1b1d32e8852f9892b0f8e6f9655938a4484a3b75343d 69540 
yubico-pam_2.26-1.debian.tar.xz
 7a44c6646c16ae0e136febd12b2934d925d0c748201cc4e7b6c55909be85b6e4 75988 
libpam-yubico-dbgsym_2.26-1_amd64.deb
 67c4607259afcb81ee6907a8bcd7110c8273a28158181f072626f0226774bd44 88900 
libpam-yubico_2.26-1_amd64.deb
 cf151c64cdc1ffce321c64ba22b6a499897abcb8a4b92097676a0ee8375b552e 6585 
yubico-pam_2.26-1_amd64.buildinfo
Files:
 8a772a33a941ae88d47242ca51e75078 1864 admin optional yubico-pam_2.26-1.dsc
 727d5937dcc864bfe6201f90f35728a5 423451 admin optional 
yubico-pam_2.26.orig.tar.gz
 19e590de5e60b9241762849dced8fb07 69540 admin optional 
yubico-pam_2.26-1.debian.tar.xz
 0a78da63ea55bd18240ce209da774d78 75988 debug optional 
libpam-yubico-dbgsym_2.26-1_amd64.deb
 16740a7a76560f82427940e202af8cc7 88900 admin optional 
libpam-yubico_2.26-1_amd64.deb
 ec1fe56f20513949cd96ac070edc09ea 6585 admin optional 
yubico-pam_2.26-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAltlUqMUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ0nyQgAqqCGWj3Kn1xsw6i1qhzGyhorHhJM
yaQNiy38ND7bf201fTMqHe3dqqn8/d2ypS+Ii6Q+wWDF4hLU/IqTzHzGWCC5gS+0
GpIAezSAxZn7LNSEfTXQp4QmbQvLGJWqHnCvZMp/Xo9b4D8rdXl8ZH195LtBFsQH
HJS5JEJYvOWYLMRLDTzGKGKl30icpvIKsUvrmFIyDNBGAtt6KueKmYl6w5xCxTNM
xfDz6IXy8+lG3dTSDhiFRMwy3OTI64u9V8vtaG8o0HhcciZdPFcNjICguNh3unLu
/WQONWofuuRO/1SjMPRaGXwRRmocFxUq7gv4J0Lh6TFsqjiI4g2ts/MP9Q==
=Ye6D
-END PGP SIGNATURE-

Accepted yubico-piv-tool 1.5.0-1 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 11 Jun 2018 21:56:06 +0200
Source: yubico-piv-tool
Binary: libykpiv1 libykpiv-dev yubico-piv-tool ykcs11
Architecture: source amd64
Version: 1.5.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Authentication Maintainers 

Changed-By: Simon Josefsson 
Description:
 libykpiv-dev - Development files for the YubiKey PIV Library
 libykpiv1  - Library for communication with the YubiKey PIV smartcard
 ykcs11 - PKCS#11 module for the YubiKey PIV applet
 yubico-piv-tool - Command line tool for the YubiKey PIV applet
Closes: 810284 859838
Changes:
 yubico-piv-tool (1.5.0-1) unstable; urgency=medium
 .
   * New upstream version.  Closes: #810284.
 - Replace libssl1.0 with libssl1.1.  Closes: #859838.
 - Depend on check.
   * Use https URLs in debian/copyright.
   * Update Standards-Version from 3.9.8 to 4.1.4.
 - Priority optional instead of extra.
   * Use compat level 11.
 - Drop no longer needed --parallel.
 - Drop no longer needed --with autoreconf.
 - Drop no longer needed --disable-silent-rules.
 - Drop no longer needed --builddirectory.
 - Drop no longer needed dh-autoreconf.
Checksums-Sha1:
 cfb98e70e3af1a6d804acb2d1e8970154e18eb62 1990 yubico-piv-tool_1.5.0-1.dsc
 9d34a99bcd6ddc98140fb15cf893853cc10ef0ae 573453 
yubico-piv-tool_1.5.0.orig.tar.gz
 6f7828fc57b1054b363866b24f8d4994e32468b8 74272 
yubico-piv-tool_1.5.0-1.debian.tar.xz
 a4d3d0fd6a288ef47a6283b9dd001d81569fef42 53848 libykpiv-dev_1.5.0-1_amd64.deb
 b3f85ff38fdf1abd6bc66309a82ad3a1849db7e4 48636 
libykpiv1-dbgsym_1.5.0-1_amd64.deb
 bc98cf52244a867bd7c4b1b05db5ff853a2061b4 49088 libykpiv1_1.5.0-1_amd64.deb
 23fdcf454f496df7a7ae448f3c1bd609f653fe31 70664 ykcs11-dbgsym_1.5.0-1_amd64.deb
 6669be5c6a44b81695f5444b80fc708fb1f7b44b 53092 ykcs11_1.5.0-1_amd64.deb
 bd1829d25480fd27ca86cd640416a382ef543599 66504 
yubico-piv-tool-dbgsym_1.5.0-1_amd64.deb
 059bdd6f66b8fd716865d53e7f4606050eef0f72 7011 
yubico-piv-tool_1.5.0-1_amd64.buildinfo
 e08a98c73a73a0fdf1c705a219f53cfffec12ca0 56316 
yubico-piv-tool_1.5.0-1_amd64.deb
Checksums-Sha256:
 23578f5bdd98565f8c2970fbde73775c9b4121c0ba96f18ea34449e4457c9e85 1990 
yubico-piv-tool_1.5.0-1.dsc
 c18375179ba25bf9d61365b3903f033f112897bbd54ca63c62fa153f2d05aaab 573453 
yubico-piv-tool_1.5.0.orig.tar.gz
 1ea67b165c42f9f2f0533472ad107507c9f36ca843e1f857708353c3a780748b 74272 
yubico-piv-tool_1.5.0-1.debian.tar.xz
 e3ade3d8d97caf3078985ba14b2871b8fa55b36ab0b2bf5534f570cb382cfc25 53848 
libykpiv-dev_1.5.0-1_amd64.deb
 71100df88b25bdd271ead9be9d77d5dfaae8ad66a1e0ebd62cc116aadd8498c2 48636 
libykpiv1-dbgsym_1.5.0-1_amd64.deb
 dddbf01c101b487417dd410303a90c98ae0d543d3a23746c291df71416aa5d6a 49088 
libykpiv1_1.5.0-1_amd64.deb
 eb0bff164d1a0b3e452eaeac0813e6ab539507e40722d76dfee930c020f3c988 70664 
ykcs11-dbgsym_1.5.0-1_amd64.deb
 3fe5593c0fe7788024d55f56ac518cbbef8691dc7c0cab157a790a3db666d054 53092 
ykcs11_1.5.0-1_amd64.deb
 7ef9b3f23cc433fe91b4ddb39c3ff60a3676a7b1b85457697985eeac4a7d547c 66504 
yubico-piv-tool-dbgsym_1.5.0-1_amd64.deb
 15339fe57b39abb3948cbc2807047e100ece7dd3f3a3f0ad1747a31ea9f3b916 7011 
yubico-piv-tool_1.5.0-1_amd64.buildinfo
 ecd770f8ba6fc5015c3516f7b0400951357106bd89f9b6fc962d40795d2b9539 56316 
yubico-piv-tool_1.5.0-1_amd64.deb
Files:
 213a07db7437524d04bdd559ceb3de5d 1990 utils optional 
yubico-piv-tool_1.5.0-1.dsc
 bcfec9fa2454ba7f7be6cc80632bd41f 573453 utils optional 
yubico-piv-tool_1.5.0.orig.tar.gz
 6453d6b4b31cd6fdcbf6582322d620f1 74272 utils optional 
yubico-piv-tool_1.5.0-1.debian.tar.xz
 bb820d285034200703d33983835388b6 53848 libdevel optional 
libykpiv-dev_1.5.0-1_amd64.deb
 2be4594d3d9572a3d2f8b3f650dd21a8 48636 debug optional 
libykpiv1-dbgsym_1.5.0-1_amd64.deb
 6458dc79c9696c5663d4d313f5ca67f2 49088 libs optional 
libykpiv1_1.5.0-1_amd64.deb
 8df4a881afc7173b4d7b4e90350172ed 70664 debug optional 
ykcs11-dbgsym_1.5.0-1_amd64.deb
 c715ac008b9b1f07d15e0074a225781f 53092 libs optional ykcs11_1.5.0-1_amd64.deb
 6f7c12951ae0d1373b7a52af86ac9e38 66504 debug optional 
yubico-piv-tool-dbgsym_1.5.0-1_amd64.deb
 b7f8153d7529ef00e3c383ed32fe57b4 7011 utils optional 
yubico-piv-tool_1.5.0-1_amd64.buildinfo
 d21fb144512b81f45e8b88fc38f110b0 56316 utils optional 
yubico-piv-tool_1.5.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlse3z4ACgkQhgt/uzL4
EZ1fGgf7BGwUkj2ejTHqRgfYwDO+82Anp+Kqfh7cR+4y7e3nXa3Q6XSgvYDQuxt7
JEM3BWGlNOZ9QB5lP5EUVTiDksL679w8GcqKsHdd3YHNJ345PmoKBniDX54ixZu/
WSOU9JT7emrUAv/9CJE82TtHk8CFjqfAItfuL9HN8pxy+3jbS2RyDyTF75sh9iMK
xQQholOp1YMt8qkIAhB7v1kOk+sMwTXWnPbStxjRM0wUt7ewdFZKeajthuzxPriD
RbHr7IykaRS+k2LLrMALQHyv8RZjuG2KKnjPJgcIQ3RU7FYu5wt5BHdSq45AguWQ
OUWBkSbWmMYil3As0rRbdeM3CtXxaw==
=n2OG
-END PGP SIGNATURE-

Accepted jabberd2 2.6.1-3 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 22 Jan 2018 10:27:08 +0100
Source: jabberd2
Binary: jabberd2
Architecture: source amd64
Version: 2.6.1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian XMPP Maintainers <pkg-xmpp-de...@lists.alioth.debian.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 jabberd2   - Jabber instant messenger server
Closes: 858935
Changes:
 jabberd2 (2.6.1-3) unstable; urgency=medium
 .
   * Update Vcs-Browser and Vcs-Git URLs to salsa.
   * Use libssl instead of libssl1.0.  Closes: #858935.
Checksums-Sha1:
 0ba9c9c96a3c72c84422368822c9fd9b5cfa70d7 1773 jabberd2_2.6.1-3.dsc
 011c909363c06b8a87d4f0ed5c16145fec7b06c5 20856 jabberd2_2.6.1-3.debian.tar.xz
 2d0a1085ab6aba327da32cf3fcb04d02726c319a 1823424 
jabberd2-dbgsym_2.6.1-3_amd64.deb
 501a362d7a1de02d4315c5b86e6826670d82aca6 6866 jabberd2_2.6.1-3_amd64.buildinfo
 390427b449f4b338740a35ee58ce623ea7239300 388332 jabberd2_2.6.1-3_amd64.deb
Checksums-Sha256:
 377f068f86c83178b5705a4bf26b3331c954276fe4927937c21a6aa0e22306c3 1773 
jabberd2_2.6.1-3.dsc
 d079f19943319aa06c399d0a3a23f295eb1abdc191a3b2121d5096dc0949ac09 20856 
jabberd2_2.6.1-3.debian.tar.xz
 b28810275322ae065fa951ac719de773f69dd9a5773e16da363e02babfcd884e 1823424 
jabberd2-dbgsym_2.6.1-3_amd64.deb
 8053cb878e83bcb4eb567c988679c9db87b44286a5056bbd7b8b2584dffd7ca1 6866 
jabberd2_2.6.1-3_amd64.buildinfo
 3272be8aad0c5ba777b20435ef6698542a5c92c261c04c97fe309d7e006d9ef9 388332 
jabberd2_2.6.1-3_amd64.deb
Files:
 f50a9124b694834cd97f1ff990bded08 1773 net optional jabberd2_2.6.1-3.dsc
 e7ca2f4bb5b97c9811cf53edf0ecf1fc 20856 net optional 
jabberd2_2.6.1-3.debian.tar.xz
 54099a8f323a266a802d3e29641f11fc 1823424 debug optional 
jabberd2-dbgsym_2.6.1-3_amd64.deb
 2a73e141a658fb89e8e332e695709f03 6866 net optional 
jabberd2_2.6.1-3_amd64.buildinfo
 6f8beea0e52ccb8504be19204a68fc1b 388332 net optional jabberd2_2.6.1-3_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlpmMUYUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3wxwgAhyHkBJNRKPjuJD6jWYfTCtEsR1ki
MCwKFx0ax0ggSf1TccfTZo4OrqmOw045z/un/FBmzgPaKaV2BODze99qldLeDEqn
dQNmmoZ5SwNNqZ7CYDrbwXtlGeVeR46Ccyl40jzLx5sQXOZJzS2gsKKd9xyEwnmJ
PllRiyPI8C7WZApMpnFDGy45IYpKo7gxg4JlASVsCLR9xiRYQqj3oVBBv6J7/lPe
Prc8PuzD9zYxpX1n6q0bXWCn2u1m1sSxcKU9muLIa3Dh3e7fmv+ZJVKFAf8LdE9j
EgYcSQIG7pspONe6dWxNHdyZ82/4m/LE1Ap7/AEw0/BPswDLPZcKlFJCcQ==
=GSSG
-END PGP SIGNATURE-

Accepted jabberd2 2.6.1-2 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 22 Jan 2018 09:27:08 +0100
Source: jabberd2
Binary: jabberd2
Architecture: source amd64
Version: 2.6.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian XMPP Maintainers <pkg-xmpp-de...@lists.alioth.debian.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 jabberd2   - Jabber instant messenger server
Changes:
 jabberd2 (2.6.1-2) unstable; urgency=medium
 .
   * Remove trailing whitespace.
 Fix lintian file-contains-trailing-whitespace.
   * Bump debhelper compat to 11.
 - Remove build-depends on dh-systemd.
 - Drop dh-autoreconf.
   * Update Standards-Version from 4.0.0 to 4.1.3.
   * Use https in copyright file.
 Fix lintian insecure-copyright-format-uri.
Checksums-Sha1:
 a5133e303a27b87c8cd509d33d013934e959954d 1816 jabberd2_2.6.1-2.dsc
 386e46759075dafa8ac3045accad8ffafc860742 17400 jabberd2_2.6.1-2.debian.tar.xz
 c579f4128ffbb7e95a175ef726645f2442f18ca5 1927816 
jabberd2-dbgsym_2.6.1-2_amd64.deb
 765a7e2667d16fb634a04376d2154f1dd1f677ed 6896 jabberd2_2.6.1-2_amd64.buildinfo
 b9c21c19b378aaa446aeb7da5e7dfa33bab1a494 386888 jabberd2_2.6.1-2_amd64.deb
Checksums-Sha256:
 bee81f3e13a8deb8d245d4fc4a42848deea6953cd004f7cc976f8a92554a66a9 1816 
jabberd2_2.6.1-2.dsc
 2bd4fe00341d8da84f6a6b9311f22bbb09cdbbb917b5653d0e7e7c8bf6879285 17400 
jabberd2_2.6.1-2.debian.tar.xz
 a933d05f0b4fa00a36d97a064f6da69b743bcad427edc8eefaa1f008ecb69471 1927816 
jabberd2-dbgsym_2.6.1-2_amd64.deb
 a0367cac38430b78f8b71b631a5a847cf2a11d18dde4c7ad2d68e731d23fc5fd 6896 
jabberd2_2.6.1-2_amd64.buildinfo
 c2821477d1d421a53d8aae49630f168325272bce6c43387444cdfe8a371693a6 386888 
jabberd2_2.6.1-2_amd64.deb
Files:
 042e333c5d2c8742039441bad2c52b79 1816 net optional jabberd2_2.6.1-2.dsc
 80cee47f8bf7547234cb404aafb07615 17400 net optional 
jabberd2_2.6.1-2.debian.tar.xz
 106829d0b9c638d95bc7c2bbf6619b42 1927816 debug optional 
jabberd2-dbgsym_2.6.1-2_amd64.deb
 4bc3aa33c9fef80cb3fc4b63cec1182b 6896 net optional 
jabberd2_2.6.1-2_amd64.buildinfo
 b383f361ed7b42fa3096066816c073af 386888 net optional jabberd2_2.6.1-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlplrpkUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3gxQgAn9YALU/dWhPOO115tQZuBm6lY/dk
Q/F686yz5DnjwYvyrIBahMXoQH0a+fmagOZ5ycrPRjU8K2GBSA+QJaeBwuCHJtto
PwDsbbLHXuZMYCtHvNaQFFTGz/MU25U/Mou0frxHPbtnOgqxijHqgvxNQx8ZallR
egyG4KlhGkJ9w9tCaH4tBiS/xkN5+8AE3cOmplCW8tOazyNSJnS2n5XXZ5oz26dq
cS2Xg5zKCxo+roOwLQIuv9npkG5wr6xTfP58TG4NdwHwZj7qVGlKx7TcZRaZ3OYt
Vpqh6SRhilcuMyCLq6smV9ZbkMwK1BE1xpnXifuXNFBGcM5jcUasLx9XsQ==
=A8Sd
-END PGP SIGNATURE-

Accepted libidn2 2.0.3-1 (source amd64 all) into unstable, unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 04 Sep 2017 11:01:44 +0200
Source: libidn2
Binary: libidn2-0 libidn2-dev libidn2-0-dev idn2 libidn2-doc
Architecture: source amd64 all
Version: 2.0.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Libidn team <help-lib...@gnu.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 idn2   - Internationalized domain names (IDNA2008/TR46) command line tool
 libidn2-0  - Internationalized domain names (IDNA2008/TR46) library
 libidn2-0-dev - Internationalized domain names (IDNA2008/TR46) development 
files
 libidn2-dev - Internationalized domain names (IDNA2008/TR46) development files
 libidn2-doc - Internationalized domain names (IDNA2008/TR46) documentation
Closes: 855948 863030 869561 872550 872567
Changes:
 libidn2 (2.0.3-1) unstable; urgency=medium
 .
   [ Ondřej Surý ]
   * New upstream version 2.0.3 (Closes: #869561)
   * Update d/watch to use gitlab.com to check new upstream releases
   * Rename the -dev package to libidn2-dev and source package to libidn2
 (Closes: #863030)
   * Merge the *.manpages and *.info into simple *.install files to
 allow easier --fail-missing run
   * Install the pkgconfig file libidn2.pc (Closes: #855948)
   * Remove runpath mangling, it looks like it's not needed anymore
   * Enable --fail-missing to catch any not-installed files
   * Add proper dbgsym-migration option for dh_strip
   * Add ruby-ronn to Build-Depends to generate the idn2.1 man page
   * Introduce libidn2-doc package and move the PDF, HTML and Info
 documentation there
   * Add lintian override for wrong embedded libidn2-0 library check on the
 package itself
   * Simplify debian/copyright to reuse license blocks
 .
   [ Simon Josefsson ]
   * Mark libidn2-dev as Multi-Arch: same.  Closes: #872550.
   * Standards-Version 4.1.0.
   * Add build-dep on gtk-doc-tools to rebuild generated content.
   * Change Priority:extra to optional as per 4.1.0.
 .
   [ Helmut Grohne ]
   * Switch libidn2-0-dev back to arch:any again. Closes: #872567.
Checksums-Sha1:
 3749167149f795947d6169f6bad8c8b4cbf38a01 1914 libidn2_2.0.3-1.dsc
 a69e0d19dc45d8871377520da8bd67c944e15604 1777895 libidn2_2.0.3.orig.tar.gz
 4eb37a56db3a3d21ba0b1beb69085f317c813912 58068 libidn2_2.0.3-1.debian.tar.xz
 9d2b68c4689d0c86ddae833050b11675c397f9a2 19310 idn2-dbgsym_2.0.3-1_amd64.deb
 90e47daa075d5b2dcb197c5716ef5a47811ee39a 22520 idn2_2.0.3-1_amd64.deb
 6b1970689ea969326ab42d09c4a83304a5e8eb37 34664 
libidn2-0-dbgsym_2.0.3-1_amd64.deb
 44774fc7f3b74f2b5e71658bdc6f6f9a846bbd06 4748 libidn2-0-dev_2.0.3-1_amd64.deb
 8a277028550289cd7bacc5e06ba800d6d0115a9c 48296 libidn2-0_2.0.3-1_amd64.deb
 f69324024e780d2f9d29fc6493683d72b9e8 62950 libidn2-dev_2.0.3-1_amd64.deb
 69c7cc7eeef3718b50b870e9ba12f007fdfa3eb5 28694 libidn2-doc_2.0.3-1_all.deb
 935497fbc0ce8c6caff40e7b0d8f7cda4b852924 10555 libidn2_2.0.3-1_amd64.buildinfo
Checksums-Sha256:
 087b674e2be98b5c059dc9d2af89f80ec6e2b7afcdd84a4beef7940e87fa0180 1914 
libidn2_2.0.3-1.dsc
 84ce902a900434a2787218b01a0d53229f75b871f5f068edcabaa3afcabca4bb 1777895 
libidn2_2.0.3.orig.tar.gz
 c8f4bc40dbf517398ab8c246a254d09a6e7b52e0e951cbb81175722b02d863ee 58068 
libidn2_2.0.3-1.debian.tar.xz
 42aa11c66551a4300530613a306e028b17bf44c683ea29e6e661262d5d9636fd 19310 
idn2-dbgsym_2.0.3-1_amd64.deb
 ba729a058a1f0a0198fa78a9c27daa35010a269c0e8fbf56e34f491edc474b9e 22520 
idn2_2.0.3-1_amd64.deb
 897f676a47c440114311ee334c92e8bed131500bedef81d515cbddb0678761e8 34664 
libidn2-0-dbgsym_2.0.3-1_amd64.deb
 2decc1a9397b627a6d1b6b925d373230d6833d59d8ead0ea81529da68ec6903c 4748 
libidn2-0-dev_2.0.3-1_amd64.deb
 7f5ccf361a2cdd1eaa285c5f5d53c5b57fb56b23e69659ce2884421e620bad1f 48296 
libidn2-0_2.0.3-1_amd64.deb
 b30b1e9b2779ebe9200da57af40880ea31ab0fc225686a96a9fe6d0fe7cf03a4 62950 
libidn2-dev_2.0.3-1_amd64.deb
 9f1424a640ec0672d231e5915d11f45a3bc6462c8f11f344b65ffcdcd3e2ea6a 28694 
libidn2-doc_2.0.3-1_all.deb
 2aacce51c1354c87ac095da424c7b872dec6dfcb473b3f373ea71b60d405e4b9 10555 
libidn2_2.0.3-1_amd64.buildinfo
Files:
 cc322d72c3a2c66dd82b09ec83d5b6cd 1914 libs optional libidn2_2.0.3-1.dsc
 ee697cba3082b03d1d126d395e3b1aea 1777895 libs optional 
libidn2_2.0.3.orig.tar.gz
 b249eaadb4cebfa7b6388a6bb0bcfc87 58068 libs optional 
libidn2_2.0.3-1.debian.tar.xz
 8a15f76d478735b3a2f46ee6197ac103 19310 debug extra 
idn2-dbgsym_2.0.3-1_amd64.deb
 a2ed033f8f30ce8fb0736b1e982caf11 22520 devel optional idn2_2.0.3-1_amd64.deb
 02027c9cc87397d5f0a50048eb1f7c11 34664 debug extra 
libidn2-0-dbgsym_2.0.3-1_amd64.deb
 8930656c74ca73612d5f33c9f548c00c 4748 oldlibs optional 
libidn2-0-dev_2.0.3-1_amd64.deb
 947efb74f3bd52af93a5c7e290c763c4 48296 libs optional 
libidn2-0_2.0.3-1_amd64.deb
 2aa4ff903aa3e562684715d64866 62950 libdevel optional 
libidn2-dev_2.0.3-1_amd64.deb
 c6f4622b2682eaed1df06d961283d5e8 28694 doc optional libidn2-doc_2.0.3-1_all.deb
 28503a356002e8842c0360052ecdd7f7 10555 libs optional 
libidn2_2

Accepted gss 1.0.3-3 (source all amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 21 Oct 2017 21:01:25 +0200
Source: gss
Binary: gss-doc gss-man libgss3 libgss-dev libgss-dbg
Architecture: source all amd64
Version: 1.0.3-3
Distribution: unstable
Urgency: low
Maintainer: Debian GSS Team <help-...@gnu.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 gss-doc- Documentation for GSS (except man pages)
 gss-man- Man pages for GSS
 libgss-dbg - Debugging symbols for GSS
 libgss-dev - Development and documentation files for Generic Security Services
 libgss3- Library for Generic Security Services
Closes: 876593
Changes:
 gss (1.0.3-3) unstable; urgency=low
 .
   * Don't build gtk-doc files pending upstream fix.  Closes: #876593.
Checksums-Sha1:
 08388e79610f474e0254b879a246ddccf3f85f5b 1864 gss_1.0.3-3.dsc
 7f5183cee804c354c59f5f9a30846067945c4f09 57000 gss_1.0.3-3.debian.tar.xz
 12fe2725947e92d78196e290dedb6580fbdf282b 843000 gss-doc_1.0.3-3_all.deb
 2581d348c31f555eaf01762d56e5d335f131c348 110956 gss-man_1.0.3-3_all.deb
 eb3542452c6e4dc1fabd17f906df64d8fbfdbaab 9126 gss_1.0.3-3_amd64.buildinfo
 0c04b2e7368313d34f12f0ae637a711d9ed3e932 107024 libgss-dbg_1.0.3-3_amd64.deb
 2ae55138574a15a9f9c32c5c9b3b4727edf95302 86048 libgss-dev_1.0.3-3_amd64.deb
 40fd9e5634372511e3d4a136af3c4185e36be059 92140 libgss3_1.0.3-3_amd64.deb
Checksums-Sha256:
 3d50a0905225727a3eda879f7e888aaf6842a808e89135bfa0b3f12824910ede 1864 
gss_1.0.3-3.dsc
 09fa2f3cc1ab3bd9e0e68d1dd2a16244556e2ebb103692051f1c598cbe78b507 57000 
gss_1.0.3-3.debian.tar.xz
 879c4ecbd5d6e0767c1023e3b39218876f35f9f377d32b9bc835b5fff36c7ab6 843000 
gss-doc_1.0.3-3_all.deb
 ec480a677c15bbe6c1197b2932f56e560c4ccc2157213d1a6d57ff762a7db694 110956 
gss-man_1.0.3-3_all.deb
 109000b64ac930900e1909486c1b1255e427a43fc6663ce9b2a7ceaf119c33f5 9126 
gss_1.0.3-3_amd64.buildinfo
 028457dec5b1664af028a5f163087dc5597d5122f79d9b935fc6dfa6d388e56e 107024 
libgss-dbg_1.0.3-3_amd64.deb
 1d6c47f3b3c35b51909ab99d81feb4f767e14802d0d51e446f8e8e7c6e56a32b 86048 
libgss-dev_1.0.3-3_amd64.deb
 3e078912f5bf386c7d543ac7ea59db989fdd4080e67903a4bc27d07101c73fc8 92140 
libgss3_1.0.3-3_amd64.deb
Files:
 3b8d82cbe005afb1c7c2862d10808821 1864 net extra gss_1.0.3-3.dsc
 ecf0888573747a14e3500941de7a4fff 57000 net extra gss_1.0.3-3.debian.tar.xz
 16ee4e3b8ed4ffdf00c00b8c8e2f39f5 843000 doc extra gss-doc_1.0.3-3_all.deb
 47093906c31aee9e82281586c33180f7 110956 doc extra gss-man_1.0.3-3_all.deb
 d576879187e0638fd7a36b3f73fc2fa3 9126 net extra gss_1.0.3-3_amd64.buildinfo
 7df09bda07883b24b6939a84fe15eb74 107024 debug extra 
libgss-dbg_1.0.3-3_amd64.deb
 126f8293f415feccaf8b5e5686c331ce 86048 libdevel extra 
libgss-dev_1.0.3-3_amd64.deb
 91cc16130d143096d11574adc347806e 92140 libs extra libgss3_1.0.3-3_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlnrnI8UHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ0y6ggAjBeslN+de96fse5lW8URlsBpxLhJ
lOArQTlqR/0gKigaI+xjlARBGH+yH8S0ta304riJOHizt3ZlirQQnjmDuE8SdbSw
ir5Gm9K+rhnvkQZlQC9y06wuFh7Mp1kqBFZnQC7B5UKbpjpn///X6YSFfL9iz3f5
sA3XEFICPhO4potpvVgkw+Eqxs8yKqFtOZyEOyGBEyu75NOszmCulb3KzuHON+U8
Atg5t7scScMEIJmbo3brvyLlm9f+1hSl7CPwRhti4vptRBsjOy0LxLKvrmotHy+2
XOJoBUV/q1GcslvY0Tbp9Dvg76vEi+jz16lMG8lEqrhaP3t4ynQC1wr56A==
=K9ki
-END PGP SIGNATURE-

Accepted yubikey-personalization 1.18.0-1 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 31 Aug 2017 12:31:21 +0200
Source: yubikey-personalization
Binary: yubikey-personalization libykpers-1-1 libykpers-1-dev
Architecture: source amd64
Version: 1.18.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 
<pkg-auth-maintain...@lists.alioth.debian.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 libykpers-1-1 - Library for personalization of YubiKey OTP tokens
 libykpers-1-dev - Development files for the YubiKey OTP personalization library
 yubikey-personalization - Personalization tool for Yubikey OTP tokens
Changes:
 yubikey-personalization (1.18.0-1) unstable; urgency=low
 .
   * New upstream release.
 - Align debian/libykpers-1-1.symbols.
   * Update Standards-Version from 3.9.8 to 4.1.0.
Checksums-Sha1:
 bf401ef528329c5a0539f57bf8777ed103a19e7f 2151 
yubikey-personalization_1.18.0-1.dsc
 acd006df352c23ad0a1623e3152614af063c1c52 518077 
yubikey-personalization_1.18.0.orig.tar.gz
 22ac85e010bb920e0444bad2f0d67d4c51bc9aba 65080 
yubikey-personalization_1.18.0-1.debian.tar.xz
 768dcf4f826d1677f1e7d2481d76844279ad7df9 52324 
libykpers-1-1-dbgsym_1.18.0-1_amd64.deb
 c9d0510bc5baf57de99d1f9d4fc65d30de2498f0 61758 libykpers-1-1_1.18.0-1_amd64.deb
 b6ba4a095d8118aef61a87dac751d0e4586f7fe0 68094 
libykpers-1-dev_1.18.0-1_amd64.deb
 759e3e16960ce6c81f9642177bfb5266b96f8968 39302 
yubikey-personalization-dbgsym_1.18.0-1_amd64.deb
 c872f70b478aba9f11909e96d4ab3c623edfaa62 6688 
yubikey-personalization_1.18.0-1_amd64.buildinfo
 2c5c80d792d5286ed2f3e1ed7f4ac7a51b1965c2 72534 
yubikey-personalization_1.18.0-1_amd64.deb
Checksums-Sha256:
 6434ff96f61dcc7e1ef0f2399475c5afa98d07e49b73ea31ebae93d8d14a9673 2151 
yubikey-personalization_1.18.0-1.dsc
 cf333e133b551adf5963e0f5fe0566f4e397f9784d4c1b8fc56b9d2ebcf982ad 518077 
yubikey-personalization_1.18.0.orig.tar.gz
 01db1323af9600ec6f0029294bf63b3a64da5ddf577b5aade40c9244f02bed4a 65080 
yubikey-personalization_1.18.0-1.debian.tar.xz
 29e9c59674abe437c75aa8f9b919874c74aa4a391be22bd155e8fc1b3694ed57 52324 
libykpers-1-1-dbgsym_1.18.0-1_amd64.deb
 f2955442619a7e908f0415c708b77f56549f78422ec649da053011345ee8e4de 61758 
libykpers-1-1_1.18.0-1_amd64.deb
 1795bceeff787f6800c5079984c8d6e0583b20c83c9a7f6e2ca331a36e1c5b32 68094 
libykpers-1-dev_1.18.0-1_amd64.deb
 496471ea9ba75b27e2d164ac6bf68909209b4807e4519f394063f8dbc9adf6cc 39302 
yubikey-personalization-dbgsym_1.18.0-1_amd64.deb
 0df80534a668e84ba203afc9b03a53ee7e64aca9e48a938813c8eac0ea831898 6688 
yubikey-personalization_1.18.0-1_amd64.buildinfo
 5f8d99f4bc5fca6457f37172448df1dd661384587e7d38ebf1d8b4f5f3c47bcc 72534 
yubikey-personalization_1.18.0-1_amd64.deb
Files:
 5e07409de6c628355f6b2cb8cc9d3189 2151 utils extra 
yubikey-personalization_1.18.0-1.dsc
 58e6a7011a3a02ae420a8eee0a442fb1 518077 utils extra 
yubikey-personalization_1.18.0.orig.tar.gz
 da3dc32b01b93942641b43f558f22045 65080 utils extra 
yubikey-personalization_1.18.0-1.debian.tar.xz
 4f3735e2187b90620c21544151f9ed35 52324 debug extra 
libykpers-1-1-dbgsym_1.18.0-1_amd64.deb
 0563bd6a92524e4e6830dd55bef8d71c 61758 libs extra 
libykpers-1-1_1.18.0-1_amd64.deb
 8843b694232b8e90bc056d71f9d06683 68094 libdevel extra 
libykpers-1-dev_1.18.0-1_amd64.deb
 4978bfedb8900f839800c3b588f68396 39302 debug extra 
yubikey-personalization-dbgsym_1.18.0-1_amd64.deb
 9465d6f554998454f441c60f3219 6688 utils extra 
yubikey-personalization_1.18.0-1_amd64.buildinfo
 dc31592cd6d323fcd226840c36d9d9d7 72534 utils extra 
yubikey-personalization_1.18.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlmn6qkUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ3yEggAoh8BpbthULjhx3RV1TGfEWMuMhfu
dUPKFDuKP+su34NOSUrSehqSp8UGwrmuS1J64HP7Yoi47x9BDqpFVo90GlCikgNX
6k74iSh6HjiYzVTHeu/q8iBtmhTTssAkUlSK8ppvtLvIntSUCxIcJpRPw6Pw3mmK
ONlYFXtx9lRWngkwwPEBaJhuHStVYFnoOsvHF9q1z3mG+x9KSISDFcLrKd0I7OQS
sJ8WRk5piB6Ipckgry2Ysqk/Vis2xGwqo4KEKrlSVeDBM6meXqjvqtndkarB0ud4
1ifFmQfLg/0CZLFtxAgckfx/Mkwh48QZFq/CDsB2DfG+afyHo0PYTP0tfg==
=5Zjx
-END PGP SIGNATURE-

Accepted yubikey-personalization 1.17.3-2 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 24 Oct 2016 13:45:17 +0200
Source: yubikey-personalization
Binary: yubikey-personalization libykpers-1-1 libykpers-1-dev
Architecture: source amd64
Version: 1.17.3-2
Distribution: unstable
Urgency: low
Maintainer: Debian Authentication Maintainers 
<pkg-auth-maintain...@lists.alioth.debian.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 libykpers-1-1 - Library for personalization of YubiKey OTP tokens
 libykpers-1-dev - Development files for the YubiKey OTP personalization library
 yubikey-personalization - Personalization tool for Yubikey OTP tokens
Closes: 836385
Changes:
 yubikey-personalization (1.17.3-2) unstable; urgency=low
 .
   * Support appstream.  Closes: #836385.
Checksums-Sha1:
 7d8ee63da8363015c5e7fd8fab53da91ebab9f06 2151 
yubikey-personalization_1.17.3-2.dsc
 d45388c77f0d6d0673c716230db80242cca0d67b 65068 
yubikey-personalization_1.17.3-2.debian.tar.xz
 5d6f1cf810605a072e5c572122111edaaad24f0d 52144 
libykpers-1-1-dbgsym_1.17.3-2_amd64.deb
 b9513533fb7d333d77bf9fcfd92e8ed71621fe35 59718 libykpers-1-1_1.17.3-2_amd64.deb
 67a5c7541a7181110d49d325cc9b33948084e62b 66062 
libykpers-1-dev_1.17.3-2_amd64.deb
 acd38f8e12fb7c4311a4f686274f9af4250c3f64 37552 
yubikey-personalization-dbgsym_1.17.3-2_amd64.deb
 eebdf3e2317f6250605eb06715053d1b17b826b5 6707 
yubikey-personalization_1.17.3-2_amd64.buildinfo
 36f6130b5a7ccbd645c626689aac01e45993ae49 69526 
yubikey-personalization_1.17.3-2_amd64.deb
Checksums-Sha256:
 88250d410a15f1db518a48aba7f994a410153d0c6e214e678b9a2877a63685a7 2151 
yubikey-personalization_1.17.3-2.dsc
 9cb2f3d54d9871131b1255d3210417df7cabaa6e858403e735b91160ef52e9ce 65068 
yubikey-personalization_1.17.3-2.debian.tar.xz
 7c6fda66e5321be0673a01b98033f81f0ae70664ddf592ca06ceab90280f99d7 52144 
libykpers-1-1-dbgsym_1.17.3-2_amd64.deb
 b30c19ee7295c6ec71031b7df05a1d940474814be1d113667358c350a8632a49 59718 
libykpers-1-1_1.17.3-2_amd64.deb
 b99d6683cac2fd4ee2305e039f59be7ce48d4e888bb01ff7b75d243802f49129 66062 
libykpers-1-dev_1.17.3-2_amd64.deb
 994689c8455924d17077ac1f3e3cd240bcfe6c3198ee6b6e8377d82e4cd9ca2f 37552 
yubikey-personalization-dbgsym_1.17.3-2_amd64.deb
 8c4408e97fa2442d545da51777698041883cdef143960ab7820bbc5d734dcbac 6707 
yubikey-personalization_1.17.3-2_amd64.buildinfo
 fd46aeeff1cb80049d9d6fcf08880ccc0f43f896f3503eadc05f069031a7773b 69526 
yubikey-personalization_1.17.3-2_amd64.deb
Files:
 405cf73fd03649557363312a5c1563f5 2151 utils extra 
yubikey-personalization_1.17.3-2.dsc
 ff77fff235acfc49f1f6a88913af9614 65068 utils extra 
yubikey-personalization_1.17.3-2.debian.tar.xz
 59ca165dc8ea3807ff7d3460c183b993 52144 debug extra 
libykpers-1-1-dbgsym_1.17.3-2_amd64.deb
 77446f65ca5417f3d085de9c245b037c 59718 libs extra 
libykpers-1-1_1.17.3-2_amd64.deb
 daacfe232302d38829ad5c91a90858ab 66062 libdevel extra 
libykpers-1-dev_1.17.3-2_amd64.deb
 d8ab177dfeef96b834d00259aacc0149 37552 debug extra 
yubikey-personalization-dbgsym_1.17.3-2_amd64.deb
 fb6fc4a792775bb72a60737263495b7e 6707 utils extra 
yubikey-personalization_1.17.3-2_amd64.buildinfo
 ba3d3b65d5eda3184f5283c578dcbd48 69526 utils extra 
yubikey-personalization_1.17.3-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlmXNHYUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ02kggAtMaLx8Dfrgr+MoB69VMNKjBVX/ei
qJtxJC4hS+ZsmpMr+w3Al6QbF7A6yh3Uv74iGfAHF3xdXVZNquFLevX1SUgdAxpL
XtlYm6f5u+ghbDX50Y0rti30wp4coYuAcQbxvbCMYNwGXVtPb7aK7qWJLF91H+Oh
fA7+hWxz9F7/xzkXT1dmW2OUjgNg0LoiIlikFUioujbGIQX5KOdf5SMBTpZ/WWrC
n9ZIn7n48lEYaNMEJSaGxeW6P3HjlwHJqOLvVj2/KSL9caTlALB7DVSu7GvAAVuU
nPHsAm7aF1OW7/CRWW4gjeb46LfxmKzZj0aZFBkf52A1uA9QTaHyIqjj3w==
=jnQ2
-END PGP SIGNATURE-

Accepted oz 0.16.0-1 (source all) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 18 Aug 2017 20:46:46 +0200
Source: oz
Binary: oz
Architecture: source all
Version: 0.16.0-1
Distribution: unstable
Urgency: low
Maintainer: Simon Josefsson <si...@josefsson.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 oz - install virtual machine guest OSs with minimal input the user
Changes:
 oz (0.16.0-1) unstable; urgency=low
 .
   * New upstream version.
   * Update Standards-Version from 3.9.8 to 4.0.0.
Checksums-Sha1:
 04d05f659fbacc3676d7a4d08b93bf42ad4be74f 1501 oz_0.16.0-1.dsc
 5e3b871c349a7ab350685619c740f8ae77330b76 141608 oz_0.16.0.orig.tar.gz
 5b443ea692ee95272bdedd578b5f492316a1d790 2876 oz_0.16.0-1.debian.tar.xz
 a0fe2d04103a40560ea35b0af135e23cd99c3abd 88686 oz_0.16.0-1_all.deb
 1832841510664830ea0a0e6d0cbf45c5b995be06 5265 oz_0.16.0-1_amd64.buildinfo
Checksums-Sha256:
 34c2e0bf4917b9ba1300d6d3eac3900aba2a97555906ab1a07a7b3211b973d4e 1501 
oz_0.16.0-1.dsc
 05112b1aa97330ae38a419d9357cd88c5d57d0e3e367307902f0e1f5b80a5459 141608 
oz_0.16.0.orig.tar.gz
 4d43d1c888fb7cbbba81b7df1fc89358b0673034b41a52586db54a71a8fc8119 2876 
oz_0.16.0-1.debian.tar.xz
 05d2a73f2733ff3d338247b8677845fd524d22d8e82a695a467937db0c784f6c 88686 
oz_0.16.0-1_all.deb
 7252676c4be52962252d9c6c6d892ac79a3a3791adf6b96b33c3032dc31c70e5 5265 
oz_0.16.0-1_amd64.buildinfo
Files:
 abda3e7b4d88fd200ab8fabc4288b165 1501 python optional oz_0.16.0-1.dsc
 e42e2dba644da014f12aa121468d518d 141608 python optional oz_0.16.0.orig.tar.gz
 80cefa84c057a2fdca13694f58cb65b5 2876 python optional oz_0.16.0-1.debian.tar.xz
 da9d657359a1ea9715cd1f6cb47540c6 88686 python optional oz_0.16.0-1_all.deb
 48b787ad9d695cd12f9324d5f7a58778 5265 python optional 
oz_0.16.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlmXNyoUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ2H9wgAqiqaiXwyoLS/4vLa8j2Lp2qzuDjd
0qp4j99DrV3Pg9gukJcEXFgzWa10QEUmTxUoGTgVQidGmQnho6UQGDwqvKoM+SPz
S8ne2LF7kd/TZfcOM7u8fPN2DToL16FBo1Qp0HEaH5BckZb9e3ncHc2nccUfiufk
vPs41iR6Hlk0S6Msfaxzi+KzSTHnvnotR1ALZQO4D1oPfO+u8Sak2GxDKGOhTwEw
IvwGxsjVCuoCOThZZXR+SfEMDs2USCogSessCvqFpbGDxuwwAJmWZE77PopDAl8Y
NJa5ZvI9mZgO6mNGv0TCecF9ziPbKEbXRS37eC3M8AHt1RTTkkXbmdIR1Q==
=D6C/
-END PGP SIGNATURE-

Accepted libu2f-host 1.1.3-1 (source amd64) into unstable

[Simon Josefsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 18 Aug 2017 20:09:57 +0200
Source: libu2f-host
Binary: libu2f-host0 libu2f-host-dev u2f-host
Architecture: source amd64
Version: 1.1.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Authentication Maintainers 
<pkg-auth-maintain...@lists.alioth.debian.org>
Changed-By: Simon Josefsson <si...@josefsson.org>
Description:
 libu2f-host-dev - Development files for the U2F host C library libu2f-host
 libu2f-host0 - Universal 2nd Factor (U2F) host communication C Library
 u2f-host   - Command line tool to do Universal 2nd Factor (U2F) operations
Changes:
 libu2f-host (1.1.3-1) unstable; urgency=medium
 .
   * New upstream version 1.1.3.
   * Bump Standards-Version.
Checksums-Sha1:
 429afc27293903df2a12a2d66498735f740b75dd 1997 libu2f-host_1.1.3-1.dsc
 dd12616d51f62607487c245adb3c4bd03b51c7d0 469480 libu2f-host_1.1.3.orig.tar.xz
 34a880406a062e351e0e79d36adaf63976d3964f 60856 
libu2f-host_1.1.3-1.debian.tar.xz
 5424feeb706ed6951c679e2f302f5b4e86ae35ab 117982 
libu2f-host-dev_1.1.3-1_amd64.deb
 ec976fd5dd1c4dc1a047565d94b760315a905d22 34226 
libu2f-host0-dbgsym_1.1.3-1_amd64.deb
 8c45d2ae17da3fa8f4d3029feda302ce96959e9b 25526 libu2f-host0_1.1.3-1_amd64.deb
 d7c27dca2c08c4256c5579648aab57bdd6617f4d 11389 
libu2f-host_1.1.3-1_amd64.buildinfo
 cc0be0cc1f465d070cbd446a13a9dddb310a70ac 14474 
u2f-host-dbgsym_1.1.3-1_amd64.deb
 35eaec2a7fae9d6834f72a0ca15af7fc750cba40 14866 u2f-host_1.1.3-1_amd64.deb
Checksums-Sha256:
 b1acf01c9b97f83b27f92c4f8930597f3e70a497ca320344babeb5e06b465ee8 1997 
libu2f-host_1.1.3-1.dsc
 3e00c1910de64e2c90f20c05bb468b183ffed05e13cb340442d206014752039d 469480 
libu2f-host_1.1.3.orig.tar.xz
 e6a5d6c473d0a3b93eef929fcff253d390f9ffbd5498c8fc6a0faebb623e743c 60856 
libu2f-host_1.1.3-1.debian.tar.xz
 ef8d55039fb5fc2abe1ac636eba219cab7c73e3167cda0f1695406e70102ce73 117982 
libu2f-host-dev_1.1.3-1_amd64.deb
 2261f2ab4b972ae3d1d4931c619d3d4a83a1fa2b10be98966cdb89dc6e81424c 34226 
libu2f-host0-dbgsym_1.1.3-1_amd64.deb
 ec82f8febf9e9b5291ea3459c520735928f06ab3cbef911b15705612dcc67033 25526 
libu2f-host0_1.1.3-1_amd64.deb
 5b972534a63adf34f0553457ba209e8fd35a6b313cee64a1249f7c36dfbb928c 11389 
libu2f-host_1.1.3-1_amd64.buildinfo
 fcd956a63c0e85f96141ae2256204522eefa508d1f6fbfb10213dce91965f387 14474 
u2f-host-dbgsym_1.1.3-1_amd64.deb
 121d1c59008ce00a867cad511708e20a545c62016e3afbdd29c1ea7beef35306 14866 
u2f-host_1.1.3-1_amd64.deb
Files:
 59ba48b8d5747f9db80d961cb7f0cfd5 1997 utils extra libu2f-host_1.1.3-1.dsc
 302b2b654d9918d128e627c0c7c09678 469480 utils extra 
libu2f-host_1.1.3.orig.tar.xz
 665d8ea2e631f8d2af8d5c86d255cec5 60856 utils extra 
libu2f-host_1.1.3-1.debian.tar.xz
 219adf6afd12f04cde4690f26dd44cd8 117982 libdevel extra 
libu2f-host-dev_1.1.3-1_amd64.deb
 12948ca27fee36f41dd72e0bb9fbf569 34226 debug extra 
libu2f-host0-dbgsym_1.1.3-1_amd64.deb
 5b5cbf6238b42be52c0f20442feddfe0 25526 libs extra 
libu2f-host0_1.1.3-1_amd64.deb
 e208f66a1e34661491dc2f5ee0f13a01 11389 utils extra 
libu2f-host_1.1.3-1_amd64.buildinfo
 be188c372ecc2465a8d63969abf0085a 14474 debug extra 
u2f-host-dbgsym_1.1.3-1_amd64.deb
 e31982d5ce8ef77babac591d6e219eaf 14866 utils extra u2f-host_1.1.3-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEmUFc4ZBdDlWp+IAmhgt/uzL4EZ0FAlmXMAcUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmcACgkQhgt/uzL4EZ0JLAgAilQ+r0ed4MnrRZPl8Zol9eQ5cUcG
sznLYHKz1xZL1YrOMYIzNtm7gyoqddP/IgOLJJLYax5YSiJ/3hs26Z2lt2XTkMHu
ws3Jhqj8dPnFxaue/pgQu5ATt2JUfYyVAT10mZUUpx0vll4uuwBc8FRjWpWa8Ukd
e6zO9/cnj8Rwyyc/Q8gvzY1Inu4BvRnzPyQBhpfsctmDrdCWqqNcPgOqt3o9Omnx
I2Ju+VwcqYO5bDrnfYxIbv/qTIo4hLFuJGPds9IPfWRaRxCpuD2XreEbaHJV78ZH
dkO0jB0puHybzddm4DH0nC4MH0aW2QXedNKnNFDVhfKjk5hbOjqF+Lczzw==
=Lsue
-END PGP SIGNATURE-