Bug#921954: Volunteer to adopt this

Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib and intend to adopt it in Debian, but I’m happy to co-maintain it. My plan is to keep it updated to latest upstream version, and see if we can offer some way for it to be used to bootstrap various projects that depend on

Re: autoreconf --force seemingly does not forcibly update everything

Guillem Jover writes: > But if as a downstream distribution I explicitly request everything to > be considered obsolete via --force, then I really do want to get whatever > is in the system instead of in the upstream package. Because then I > can fix things centrally in a distribution dependency

Re: autoreconf --force seemingly does not forcibly update everything

Guillem Jover writes: > But if as a downstream distribution I explicitly request everything to > be considered obsolete via --force, then I really do want to get whatever > is in the system instead of in the upstream package. Because then I > can fix things centrally in a distribution dependency

Re: autoreconf --force seemingly does not forcibly update everything

Eric Blake writes: > Widening the audience to include bug-gnulib, which is the upstream > source of "# build-to-host.m4 serial 3" which was bypassed by the > malicious "# build-to-host.m4 serial 30". > > On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote: >> Hi! >> >> While analyzing

Re: autoreconf --force seemingly does not forcibly update everything

Eric Blake writes: > Widening the audience to include bug-gnulib, which is the upstream > source of "# build-to-host.m4 serial 3" which was bypassed by the > malicious "# build-to-host.m4 serial 30". > > On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote: >> Hi! >> >> While analyzing

Re: Validating tarballs against git repositories

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 -f

Re: Validating tarballs against git repositories

"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

Re: Git and SHA1 collisions

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

Re: xz backdoor

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

Re: [Trisquel-devel] riscv64 for trisquel 12?

Luis Guzman writes: > Hi again!, > > En 30/03/24 06:13, Simon Josefsson escribió: >> Hi. What would it take to enable riscv64 when we import 24.04 as the >> base for trisquel 12? > > Talking from my own point of view, need more people involved on the > develop

Re: Validating tarballs against git repositories

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 analys

Re: Validating tarballs against git repositories

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

Re: Validating tarballs against git repositories

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 analys

[Trisquel-devel] riscv64 for trisquel 12?

Hi. What would it take to enable riscv64 when we import 24.04 as the base for trisquel 12? While still a fairly experimental platform, I think that during the lifespan of trisquel 12 the riscv64 platform may become an important target. It would be nice to include riscv64 packages from Ubuntu

Re: RFS: golang-github-go-git-go-git [RC] & dependencies

Nilesh Patra writes: >> > https://github.com/go-git/go-git-fixtures/tree/master/data >> > >> > directly into the installed Debian package. Given the recent xz fiasco, >> > I have doubts that this is a good idea -- there is a bunch of >> > pre-generated compressed git repositories in that

Re: RFS: golang-github-go-git-go-git [RC] & dependencies

Maytham Alsudany writes: > Hi Simon, > > On Sat, 2024-03-30 at 09:48 +0100, Simon Josefsson wrote: >> Maytham Alsudany writes: >> >> > https://salsa.debian.org/go-team/packages/golang-github-go-git-go-git-fixtures >> >> I looked at this update, and

Re: Validating tarballs against git repositories

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 >

Re: [Trisquel-devel] Trisquel 11.0.1 new ISO set for testing

What a great easter gift! I have successfully installed it on a Talos II Lite using trisquel-netinst_11.0.1_ppc64el.iso image with SHA256 3b4822f154631ce4348259720f4a2f5aa94bdc4e52e75a782f33355044aa8125. Notes: - Petitboot defaults to select 'Expert Install' instead of 'Default Install' - not

Re: Validating tarballs against git repositories

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

Re: RFS: golang-github-go-git-go-git [RC] & dependencies

Maytham Alsudany writes: > https://salsa.debian.org/go-team/packages/golang-github-go-git-go-git-fixtures I looked at this update, and one of the proposed changes is to include all of the pre-generated stuff from here: https://github.com/go-git/go-git-fixtures/tree/master/data directly into

Re: RFS: golang-github-go-git-go-git [RC] & dependencies

Maytham Alsudany writes: > Hi Simon, > > On Wed, 2024-03-27 at 16:30 +0100, Simon Josefsson wrote: >> Hi -- happy to sponsor this -- are they in git on salsa for me to build >> and sign and upload, or what shape are they in? > > They all ready to sign and upload. I

Re: Adding ECC KEM

NIIBE Yutaka writes: > Hello, > > In the task T6755, we introduced KEM API. ML-KEM is added. > > Today, I'd like to propose adding ECC KEM implementation in the API. > The intention of mine is use in gpg-agent to support PQC (task T7014). > > Attached is a patch adding ECC KEM for X25519.

Re: RFS: golang-github-go-git-go-git [RC] & dependencies

tor 2024-03-28 klockan 07:29 +0800 skrev Maytham Alsudany: > Hi Simon, > > On Wed, 2024-03-27 at 17:14 +0100, Simon Josefsson wrote: > > I wonder if the sha1cd test data is copyrighted and licensed as per > > upstream's claims, but I have no fact to speak against the clai

[Bug 2015570] Re: libresolv-wrapper does not work on 22.04, may just need rebuild

Related analysis: https://bugzilla.samba.org/show_bug.cgi?id=14830 It appears to affect Debian too: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1067838 ** Bug watch added: Samba Bugzilla #14830 https://bugzilla.samba.org/show_bug.cgi?id=14830 ** Bug watch added: Debian Bug tracker

Re: RFS: golang-github-go-git-go-git [RC] & dependencies

Maytham Alsudany writes: > Hi Go team, > > I require a sponsor to review and upload the following packages for me. > > New packages: > - golang-github-pjbgf-sha1cd > - golang-github-skeema-knownhosts I reviewed these, and have uploaded them. Builds fine:

Bug#1067838: [Pkg-sssd-devel] Bug#1067838: Please provide a trivial working example

Thanks -- alas I think this is the same as this one: https://bugs.launchpad.net/ubuntu/+source/resolv-wrapper/+bug/2015570 Rebuild the binary package and installing it should make things work again. Could you try that? I'm not sure how to express this dependency, it seems some behaviour of

Bug#1067734: coreutils: touch --date y2k38 on armhf

Package: coreutils Version: 9.4-3.1 Hi. Shouldn't dates past 2038 work on armhf? I tried the following commands in a sid chroot on abel.debian.org -- it seems 'date' handles y2k38 properly, but not 'touch --date'. I couldn't find any earlier bug report about touch --date not handling y2k38.

Re: [PATCH] maint: Allow gnulib's readutmp module to use systemd.

Bruno Haible writes: > Hi Simon and Collin, > >> > Could putting the following into bootstrap.conf be a method that >> > we could recommend? Then developers can override it with >> > GNULIB_TOOL_IMPL=sh ./bootstrap if they want. >> > >> > GNULIB_TOOL_IMPL=${GNULIB_TOOL_IMPL:-py} >> >> I'd

Re: [GNU-linux-libre] Qualcomm Atheros AR9462 AER errors

Edgar Lux via gnu-linux-libre writes: > Hello. I would like to bring this to your kind attention: > > https://labs.parabola.nu/boards/11/topics/1679 I had the same problem on linux-libre 6.0 via Trisquel aramo:

Re: [PATCH] maint: Allow gnulib's readutmp module to use systemd.

(moving to bug-gnulib) Collin Funk writes: > On 3/22/24 2:18 PM, Simon Josefsson wrote: >> Upgrading inetutils to use gnulib-tool.py would be nice. As a start, I >> bumped the gnulib submodule. > > Bruno and I are still working on it with a test suite. We want the >

Re: [PATCH] maint: Allow gnulib's readutmp module to use systemd.

Collin Funk writes: > Hi Simon, > > On 3/22/24 12:51 PM, Simon Josefsson wrote: >> Hi. Nice catch, thank you. I have added a CI/CD job to catch -lsystemd >> regressions in the future: > > Nice, looks good to me. > >> Thank you for details -- I think t

Re: [PATCH] maint: Allow gnulib's readutmp module to use systemd.

Collin Funk writes: > When building on GNU/Linux with: > > ./configure --enable-systemd > > there are linker errors due to '-lsystemd' not being passed to the > linker. This is used by Gnulib's readutmp module. Hi. Nice catch, thank you. I have added a CI/CD job to catch -lsystemd regressions

Bug#1066848: freediameter: replace libidn11-dev with libidn-dev

Hi again, I have uploaded a NMU with the patch below into DELAYED/10. Let me know if you want to cancel it. /Simon Simon Josefsson writes: > Hi Ruben, all, > > I have opened a merge request to resolve the bug below: > > https://salsa.debian.org/debian-mobcom-te

Re: gnulib-tool: Obey environment variable GNULIB_TOOL_IMPL

Collin Funk writes: >> But in the current state, it fails for nearly every command. There's >> no hope that you can expect identical results from the two implementations >> as long as there are still items in the TODO list. > > Yes. I am working on it. I've added the following lines to my >

Bug#1062896: shishi: NMU diff for 64-bit time_t transition

* Non-maintainer upload. > + * Rename libraries for 64-bit time_t transition. Closes: #1062896 > + > + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 + > + > shishi (1.0.3-2) unstable; urgency=medium > >[ Simon Josefsson ] > diff -Nru shishi-1.0.3/debian/contr

Bug#1062896: shishi: NMU diff for 64-bit time_t transition

* Non-maintainer upload. > + * Rename libraries for 64-bit time_t transition. Closes: #1062896 > + > + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 + > + > shishi (1.0.3-2) unstable; urgency=medium > >[ Simon Josefsson ] > diff -Nru shishi-1.0.3/debian/contr

Bug#1062896: shishi: NMU diff for 64-bit time_t transition

* Non-maintainer upload. > + * Rename libraries for 64-bit time_t transition. Closes: #1062896 > + > + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 + > + > shishi (1.0.3-2) unstable; urgency=medium > >[ Simon Josefsson ] > diff -Nru shishi-1.0.3/debian/contr

Bug#1066855: drop libidn11-dev

Package: libidn Version: 1.42-1 All packages should build against libidn-dev now, not libidn11-dev. Current stable release of Debian ships libidn-dev. The transitional libidn11-dev package can be dropped when all reverse dependencies have stopped using it. root@68d340bc8331:/# apt-cache

Bug#1066848: freediameter: replace libidn11-dev with libidn-dev

Simon Josefsson writes: > Package: freediameter > Version: 1.2.1-8 > Tags: patch > > Hi! I'd like to drop the transitional package 'libidn11-dev' as most > packages have already moved to use 'libidn-dev' which is in stable. > > How about this patch? > > /Simon >

Bug#1066848: freediameter: replace libidn11-dev with libidn-dev

Package: freediameter Version: 1.2.1-8 Tags: patch Hi! I'd like to drop the transitional package 'libidn11-dev' as most packages have already moved to use 'libidn-dev' which is in stable. How about this patch? /Simon diff --git a/debian/control b/debian/control index 335362a..2856eae 100644

Bug#1066846: loudmouth: replace libidn11-dev with libidn-dev

Package: loudmouth Version: 1.5.4-1 Tags: patch Hi! I'd like to drop the transitional package 'libidn11-dev' as most packages have already moved to use 'libidn-dev' which is in stable. How about this patch? /Simon diff --git a/debian/control b/debian/control index 853b197..963b1c3 100644 ---

Re: planning for beta-testing gnulib-tool.py

I like the plan to replace gnulib-tool with a faster implementation, and a two-year migration phase sounds reasonable to see if it will work in practice. Trying gnulib-tool.py on OATH Toolkit (which use a somewhat unorthodox gnulib usage style by adding code into git) results in error below. I

Re: planning for beta-testing gnulib-tool.py

Bruno Haible writes: > I guess we are thinking about slightly different things: > > * (A) I am thinking about > - for P in { coreutils, gettext, ... }, taking a frozen(!) checkout of P, > removing irrelevant source files (esp. all *.h, *.c, documentation, > etc.), > - and a

Re: planning for beta-testing gnulib-tool.py

Bruno Haible writes: > 5) Possibly it makes also sense to allow GNULIB_TOOL_IMPL to be set to >'sh+py'. In this case the script will make a full copy of the destination >dir, run the shell implementation and the Python implementation on the >two destination dirs, separately, and

Re: pam_oath with user_unknown=ignore

Dirk van Deun writes: > On Wed, Mar 06, 2024 at 09:11:54PM +0100, Simon Josefsson wrote: >> Dirk van Deun writes: >> >> > Hi, >> > >> > I really like the fact that you can use user_unknown=ignore to >> > introduce pam_oath gradually, and it

Re: pam_oath with user_unknown=ignore

Dirk van Deun writes: > Hi, > > I really like the fact that you can use user_unknown=ignore to > introduce pam_oath gradually, and it works fine if you use one users > file to store all the secrets; but when you use a file per user > (like with usersfile=/oath/${USER}), users that do not have a

Bug#1063220: oath-toolkit: NMU diff for 64-bit time_t transition

Benjamin Drung writes: > Source: oath-toolkit > Dear maintainer, > > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. > > Note that this adds a versioned build-dependency on dpkg-dev, to guard > against accidental

Bug#1063220: oath-toolkit: NMU diff for 64-bit time_t transition

Benjamin Drung writes: > Source: oath-toolkit > Dear maintainer, > > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. > > Note that this adds a versioned build-dependency on dpkg-dev, to guard > against accidental

Bug#1063220: oath-toolkit: NMU diff for 64-bit time_t transition

Benjamin Drung writes: > Source: oath-toolkit > Dear maintainer, > > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. > > Note that this adds a versioned build-dependency on dpkg-dev, to guard > against accidental

Bug#1064454: debian-policy: Restrict deb822 field names more

Would it make sense to change this to use an inclusive list of permitted characters instead? How about checking the field names that is in use today, and construct a regexp of permitted symbols out of that? Starting point: [A-Za-z][A-Za-z0-9-_]* /Simon signature.asc Description: PGP signature

Bug#1064454: debian-policy: Restrict deb822 field names more

Would it make sense to change this to use an inclusive list of permitted characters instead? How about checking the field names that is in use today, and construct a regexp of permitted symbols out of that? Starting point: [A-Za-z][A-Za-z0-9-_]* /Simon signature.asc Description: PGP signature

Bug#1064397: ITP: client-desktop-shell-integration-nautilus -- Nautilus, Nemo and Caja integration of the owncloud-client

Pierre-Elliott Bécue writes: > Package: wnpp > Severity: wishlist > Owner: Pierre-Elliott Bécue > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: client-desktop-shell-integration-nautilus > Version : 5.0.0 > Upstream Contact: Frank Müller > * URL :

Bug#1064397: ITP: client-desktop-shell-integration-nautilus -- Nautilus, Nemo and Caja integration of the owncloud-client

Pierre-Elliott Bécue writes: > Package: wnpp > Severity: wishlist > Owner: Pierre-Elliott Bécue > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: client-desktop-shell-integration-nautilus > Version : 5.0.0 > Upstream Contact: Frank Müller > * URL :

Bug#1063746: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

Tom Parkin writes: > Hi folks, > > Would someone mind please reviewing and uploading > golang-github-katalix-go-l2tp 0.1.7-1? > > https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp Looks good, although there were no tag for the previous Debian upload so diffing changes was

Bug#1063746: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

Tom Parkin writes: > Hi folks, > > Would someone mind please reviewing and uploading > golang-github-katalix-go-l2tp 0.1.7-1? > > https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp Looks good, although there were no tag for the previous Debian upload so diffing changes was

Re: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

Tom Parkin writes: > Hi folks, > > Would someone mind please reviewing and uploading > golang-github-katalix-go-l2tp 0.1.7-1? > > https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp Looks good, although there were no tag for the previous Debian upload so diffing changes was

Re: gnulib-tool caching

Bruno Haible writes: > Simon Josefsson wrote: >> is it possible to design a reliable >> caching mechanism? Something similar to CONFIG_SITE for autoconf? > > CONFIG_SITE is not reliable; that's the problem with it... > >> I find that ./gnulib-tool takes a long

Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.

Bruno Haible writes: >> What is the status of the Python gnulib tool? I'm not sure how far >> behind it is compared to the shell script but it seems like it would >> be much faster. I would say more maintainable but I might just be bad >> at writing shell scripts. :) > > Yes, it's the hope that

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

Bruno Haible writes: > --- a/top/maint.mk > +++ b/top/maint.mk > @@ -503,6 +503,7 @@ sc_prohibit_have_config_h: > # Nearly all .c files must include . However, we also permit this > # via inclusion of a package-specific header, if cfg.mk specified one. > # config_h_header must be suitable

Re: grpc transition

Shengjing Zhu writes: > My last attempt for the grpc-go transition is stuck at the protobuf things. > One thing that might help is gprc-go is finally going to use the new > protobuf library, https://github.com/grpc/grpc-go/pull/6961 > So we could decouple the grpc-go transition from the protobuf

Re: grpc transition

Mathias Gibbens writes: > To me it seems like the extra work to try to keep a small set of > packages building with a "golang-google-grpc-legacy" package wouldn't > be worthwhile in the long term. I'd prefer effort be focused on getting > the current grpc working in experimental, and uploading

Re: Package dependencies on protobuf libraries

Simon Josefsson writes: > Mathias Gibbens writes: > >>>   * golang-etcd-server-dev >>>   * golang-github-go-kit-kit-dev >>>   * golang-github-grpc-ecosystem-go-grpc-middleware-dev >>>   * golang-github-grpc-ecosystem-grpc-gateway-dev >

Bug#1064021: gss: FTBFS on armhf: FAIL: krb5context

Sebastian Ramacher writes: > FAIL: krb5context > = > > ==31890== > ==31890== Process terminating with default action of signal 11 (SIGSEGV) > ==31890== Access not within mapped region at address 0xBDB33984 > ==31890==at 0x4856C00: shishi_key_parse (in >

Bug#1064021: gss: FTBFS on armhf: FAIL: krb5context

Sebastian Ramacher writes: > FAIL: krb5context > = > > ==31890== > ==31890== Process terminating with default action of signal 11 (SIGSEGV) > ==31890== Access not within mapped region at address 0xBDB33984 > ==31890==at 0x4856C00: shishi_key_parse (in >

Bug#1064021: gss: FTBFS on armhf: FAIL: krb5context

Sebastian Ramacher writes: > FAIL: krb5context > = > > ==31890== > ==31890== Process terminating with default action of signal 11 (SIGSEGV) > ==31890== Access not within mapped region at address 0xBDB33984 > ==31890==at 0x4856C00: shishi_key_parse (in >

Re: RFS: golang-google-grpc + golang-github-google-s2a-go

as some frustration trying to fix the FTBFS packages... I'll try to take a look at some more of the FTBFS packages below, but my lack of Go knowledge is a limiting factor... /Simon Simon Josefsson writes: > Simon Josefsson writes: > >> Further progress on grpc. I've rebuilt 1.60

Re: Package dependencies on protobuf libraries

Mathias Gibbens writes: >>   * golang-etcd-server-dev >>   * golang-github-go-kit-kit-dev >>   * golang-github-grpc-ecosystem-go-grpc-middleware-dev >>   * golang-github-grpc-ecosystem-grpc-gateway-dev >>   * golang-github-openzipkin-zipkin-go-dev > > Not having heard any objections, I'll plan

Re: Update of golang-github-asaskevich-govalidator

FYI, I have uploaded golang-github-asaskevich-govalidator to unstable, version >=11 is needed by rekor. Rekor target targets experimental but we might as well try to get each reverse dependency into unstable when that is possible. /Simon signature.asc Description: PGP signature

golang-github-katalix-go-l2tp

Tom Parkin writes: > On Tue, Jan 23, 2024 at 18:05:23 +0100, Simon Josefsson wrote: >> Tom Parkin writes: >> >> > Hi Simon, >> > >> > On Mon, Jan 22, 2024 at 20:15:11 +0100, Simon Josefsson wrote: >> >> golang-github-katalix-go-l2tp

Re: SemVer.org compatible updates and rebuilding reverse dependencies

Praveen Arimbrathodiyil writes: > On 14/2/24 8:03 AM, Mathias Gibbens wrote: >> On Mon, 2024-02-12 at 19:08 +0530, Praveen Arimbrathodiyil wrote: >>> Do we assume SemVer.org compliance for modules with >= 1.0 versions? >>> >>> ie, should we assume things will break for every minor updates as >>>

Re: RFS: golang-google-grpc + golang-github-google-s2a-go

Jérémy Lal writes: > Le lun. 12 févr. 2024 à 22:11, Simon Josefsson a > écrit : > >> Jérémy Lal writes: >> >> > golang-github-grpc-ecosystem-go-grpc-prometheus should be deprecated in >> > debian as well, and replaced by >> > https://github.com/g

Re: RFS: golang-google-grpc + golang-github-google-s2a-go

Jérémy Lal writes: > golang-github-grpc-ecosystem-go-grpc-prometheus should be deprecated in > debian as well, and replaced by > https://github.com/grpc-ecosystem/go-grpc-middleware > > First move is to report a RC-bug on that package, so it gets removed from > testing if no one steps in. >

Re: RFS: golang-google-grpc + golang-github-google-s2a-go

Simon Josefsson writes: > Further progress on grpc. I've rebuilt 1.60.1 with some EXCLUDE fixes > thanks to help on irc, we've gone from 22 reverse build failures down to > 16 failures, here is the pipeline: > > https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/629139

Re: RFS: golang-google-grpc + golang-github-google-s2a-go

Simon Josefsson writes: > Further progress on grpc. I've rebuilt 1.60.1 with some EXCLUDE fixes > thanks to help on irc, we've gone from 22 reverse build failures down to > 16 failures, here is the pipeline: > > https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/62913

Re: Backporting podman

Krumelmonster writes: > Dear go package maintainers, > > I would like to see podman>=4.4 make it into bookworm backports so the > excellent quadlet feature would become available in debian stable. I'm > inexperienced in debian packaging and gave up on my first attempt in > creating this

Re: Let's remove Gnulib's ctime module

Bruno Haible writes: > Paul Eggert wrote: >> >> So CTIME_BUFSIZE should be 35? >> > With 50 years of computer science experience, we should have learned >> > the lesson to allocate more room than sounds necessary*now*. If >> > now you think 35 will be sufficient for all times, then we should >>

Re: Let's remove Gnulib's ctime module

tring functions. Copyright (C) 2024 FSF Authors: Paul Eggert, Bruno Haible, Simon Josefsson License: LGPL-2+ */ #include #include /* This evaluates to 35 on typical machines today, and will grow automatically if time_t gets wider - it could even exceed 70 if needed. 7 = fl

Re: Let's remove Gnulib's ctime module

How about this (or gl-ctime?): /* safer-ctime.h -- safer version of ctime(). Copyright (C) 2024 FSF Authors: Paul Eggert, Bruno Haible, Simon Josefsson License: LGPL-2+ */ #define SAFER_CTIME_BUFSIZE 35 /* Convert WHEN representing the number of seconds before/after epoch, 1970-01

Re: Transparency into private keys of Debian

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

Re: Let's remove Gnulib's ctime module

Paul Eggert writes: > and we can package this up into a function like this: > > char c[CTIME_BUFSIZE]; > safer_ctime (c, *tp); > > if people prefer simplicity. Yes please. Using complex APIs to implement safer_ctime is fine, but I would prefer to not make existing ctime code more

Re: Transparency into private keys of Debian

> > 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

Re: Transparency into private keys of Debian

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

Re: ctime uses in inetutils

Simon Josefsson via Bug reports for the GNU Internet utilities writes: > FYI, I have reluctantly needed convince myself that inetutils has bugs > related to ctime for years < 1000 or year > and that this is > something that needs to be fixed rather than ignored as irrelevant

ctime uses in inetutils

FYI, I have reluctantly needed convince myself that inetutils has bugs related to ctime for years < 1000 or year > and that this is something that needs to be fixed rather than ignored as irrelevant (which was my initial reaction):

Re: Let's remove Gnulib's ctime module

You convinced me inetutils (and many other programs) has real bugs related to ctime today that should be fixed. Now I want to figure out what the best fix to existing code is. Paul Eggert writes: >> Another idea is to have gnulib's ctime augment the C standard to have >> ctime not be undefined

Re: Transparency into private keys of Debian

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.

Re: Let's remove Gnulib's ctime module

Here are some examples of ctime usage in GNU InetUtils, starting with inetd (a single-threaded application): https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/inetd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1710 This prints day of time of the system. While we could rewrite that to

Re: Transparency into private keys of Debian

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 expl

Re: Let's remove Gnulib's ctime module

mån 2024-02-05 klockan 00:59 -0800 skrev Paul Eggert: > On 2024-02-05 00:16, Simon Josefsson wrote: > > didn't see anything in your patch that would warn about usage of > > ctime? > > Would it make sense for a gnulib ctime module to NOT replace ctime > > but > &g

Re: Let's remove Gnulib's ctime module

Paul Eggert writes: > This recent bug relating to ctime suggests that the ctime module is > more trouble than it's worth now. I propose that we remove > it. Proposed patch attached (but not installed). Intresting approach -- I don't mind changing any ctime calls to strftime in code I come

Re: Transparency into private keys of Debian

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

Re: Transparency into private keys of Debian

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 >> tru

Update of golang-github-asaskevich-govalidator

Hi Rekor needs a newer version of golang-github-asaskevich-govalidator: github.com/sigstore/rekor/cmd/rekor-cli/app # github.com/sigstore/rekor/cmd/rekor-cli/app src/github.com/sigstore/rekor/cmd/rekor-cli/app/validate.go:45:16: undefined: validator.IsSHA512

Re: cannot make gcc report undeclared builtins

ons 2024-01-31 klockan 16:46 -0800 skrev Paul Eggert: > On 1/31/24 03:23, Simon Josefsson via Bug reports for autoconf wrote: > > > https://buildd.debian.org/status/fetch.php?pkg=libidn2=loong64=2.3.7-1=1706360630=0 > > > Here's the crucial part of that log: > >

Transparency into private keys of Debian

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

cannot make gcc report undeclared builtins

Hi I got this failure on a loong64 machine for libidn2 that was bootstrapped with autoconf 2.72: checking for gcc options needed to detect all undeclared functions... cannot detect configure: error: in `/<>/build': configure: error: cannot make gcc report undeclared builtins For full log:

libidn2-2.3.7 released [stable]

to this release: Fangrui Song (1) Simon Josefsson (46) Tim Rühsen (9) alittle (1) zhuofeng (1) Happy hacking, Simon == Here is the libidn2 home page: https://www.gnu.org/software/libidn/#libidn2 Manual: https://www.gnu.org

Re: 2.5, 2.4 and 2.3 of inetutils...

Marty Kazmaier writes: > All give me: > > tftpsubs.c:68:10: fatal error: arpa/tftp.h: No such file or directory >68 | #include > > > When running 'make' on them. ./configure runs fine. I'm using > Windows 10 x64 Pro. What could I possibly be doing wrong? I don't > think I'm missing any

Bug#1061555: apt: augment signature verification for key-usage transparency (Sigstore/Sigsum)

Julian Andres Klode writes: > I'm strongly opposed to add support for these off-the-shelve solutions. > We need end-to-end control of all aspects of signing. > > What we learned with OpenPGP is that we don't want to be tied to third > party off-the-shelve solutions as we cannot control the

Bug#1061555: apt: augment signature verification for key-usage transparency (Sigstore/Sigsum)

Package: apt Severity: wishlist I believe it would be nice if apt could verify signatures from Sigstore cosign and/or verify Sigsum proofs, to augment the current PGP-based signature verification. While this can be handled outside of apt's awareness, it would also be possible for apt to support

<    1   2   3   4   5   6   7   8   9   10   >