Bug#1061142: ITP: python-crispy-bootstrap4 -- Bootstrap 4 template pack for django-crispy-forms
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-crispy-bootstrap4 Version : 2023.1 Upstream Contact: David Smith * URL : https://github.com/django-crispy-forms/crispy-bootstrap4 * License : Expat Programming Lang: Python Description : Bootstrap 4 template pack for django-crispy-forms Bootstrap4 template pack for django-crispy-forms. This template pack was included with the core django-crispy-forms package until version 2.0. I intend to maintain it as part of DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmWqYmAbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqJG8H/3zBQeDFQDOpA7zyIKvm ycvac4e+Dfzj4cmodrsJOwUYKxQ2w1Y7P+wkoia+7RjdEDLn/qdbauii2JPyNxww 1p3OnA1MMjx1SHXy0BQos7Zdt0I7xGugpVAuX8Cv/rhDYNW6bF+GCI7glzlxvMGg AzjfJwr5Xnl7AoGl1G/OzHJdnlVfcpbBEnYtNZcdzP0igfrpTzXbdNP28AIy1iU1 we/pgbGGM6exd/yxAMmvYAwIrXO4KPMMjUyGcDjljb8pcPYeDYPwPZBMP1ZtD3ML 4JOG8pwm6+NgjZVmfybhutVG5/4UWRywGk2zr2lGFlZMwmIsYZzGCyuZLUsGrL7T DYU= =EBwq -END PGP SIGNATURE-
Re: Limited security support for Go/Rust? Re ssh3
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. > Please show practical problems with it? * not working on new archs (most of the work of making sure autoconfage gets rebuilt was done by arm64 porters when it was a new thing) * not being able to fix bugs in autoconfage * failing to adapt to changes in the toolchain > 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_. Thus, I say the problem with vendored libraries is mostly unrelated to that of static linking, and thus they don't need to share a solution. > Here the problem is embedded into the language oekosystem itself. It is > not a choice of the software author to do static linking. It's mostly an issue with the deployment scheme at Google: I heard they recompile all their software and reinstall it on their fleet EVERY WEEK. This is about the only case where non-special-case (/sbin/ldconfig etc) static linking works. Then they shared their internal project with the world (good) without caring how it affects others (bad). Unlike them, we can't rebuild the world every time a bug is fixed (security or not). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁'Russkiy voyennyi korabl, idi nakhuy' ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: Limited security support for Go/Rust? Re ssh3
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#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums
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
Debtags: understanding the heuristics of "Checks and hints" in the online editor
Hi, I want to use debtags metadata for a research project, but I'll need to improve it to get good results (I'll use it for thousands of packages). I started contributing, by adding and removing some tags using the online tag editor, but the "Checks and hints" part seems wrong to me in several cases. For instance,with package alsamixergui: I downloaded the source code, and it contains exclusively C++ sources and headers. I don't see a single C source nor header. However, the package has the tag "implemented-in::C". And if I replace it with "implemented-in::C++", the "Checks and hints" part of the tag editor still claims: "There is a 100% chance that the tag implemented-in::C is missing". So, either I misunderstood its meaning, or there is an issue with the heuristics. Could someone please clarify it to me? -- André Maroneze Researcher/Engineer CEA/List Software Safety and Security Laboratory
Please help test the PAM in experimental
There are a number of changes, and I'd just like a bit more confidence that it works as expected before uploading to unstable in about a week. Changes include: * Running pam_umask with usergroups support by default. * libpam-modules now depends on libsystemd0 because utmp is not y2038-clean and upstream has decided to depend on elogind for that. * New PAM upstream and thus newly rebased patches. So, it would be helpful especially if you would install libpam-modules and libpam0g from experimental. signature.asc Description: PGP signature
Bug#1061158: ITP: discord-rpc -- library for Discord Rich Presence integration
Package: wnpp Severity: wishlist Owner: David James X-Debbugs-Cc: debian-devel@lists.debian.org, davidjamescastor...@proton.me * Package name: discord-rpc Version : 3.4.0 Upstream Contact: Discord, Inc * URL : https://github.com/discord/discord-rpc * License : MIT Programming Lang: C, C++, CMake, Python Description : library for Discord Rich Presence integration This is a library for integrating Discord features into games and applications. For example, it allows an application to connect to Discord and show in-game activity on a user's profile. It is also a Citra dependency. There are multiple FOSS projects aside from Citra that also integrate this library and could make use of this package if they were ever packaged themselves (e.g. Duckstation, PCSX2 etc.). I would be maintaining this package myself, but would need a sponsor.
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
On Fri, 2024-01-19 at 18:24 +0100, André Maroneze wrote: > I want to use debtags metadata for a research project The debtags service is planned to be shutdown and the data no longer published, as there is no-one in Debian who wants to maintain it. https://lists.debian.org/msgid-search/20231126160111.7nr56b7oje6uw...@enricozini.org > I started contributing, by adding and removing some tags using the > online tag editor, but the "Checks and hints" part seems wrong to me > in several cases. Sounds like there may be bugs that need fixing, but first there would need to be a new maintainer who could take over the project. If you were willing to be the primary code maintainer, perhaps you could find some Debian member willing to be the service maintainers and review and deploy all of the changes you could make, at least until you become a Debian member on the basis of your debtags and other contributions. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi again,
On Sun, Jan 07, 2024 at 01:09:48PM +0100, Rene Engelhard wrote:
> Am 07.01.24 um 04:38 schrieb Steve Langasek:
> > The ordering here would be:
> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags
> > - the source packages which need an ABI change
> >("source-packages"+"lfs-and-depends-time_t") and do not already have
> >versions in experimental, will have sourceful NMUs to experimental with
> >the new binary package names in order to clear binary NEW, in
> > coordination
> > - once these packages have all cleared binary NEW, the new dpkg defaults
> >will be uploaded to unstable
> And in the meanwhile in experimental it will be built with the old time_t on
> other architectures.
> Since the new dpkg won't be picked up.
> Not in the experimental builders unstable+experimental chroots which only
> install experimental packages when Build-Depends: need them.
> (For an undefined time given how much the packages later in the chain wait
> in NEW)
> Especially on armhf which is affected. Or will you do the source NMUs on
> armhf/i386? (For some packages where some features are disabled on 32bit
> this is probably not a good idea)
There is no intention here to do the source NMUs on armhf/i386; they will be
done on amd64.
Yes, autobuilds of these packages in experimental would, in the naive
implementation, still build with the old ABI and the new name.
I am not overly concerned about this, experimental is a staging ground for
developers and not something that folks are intended to install from in
production. And there would be very few if any reverse-dependencies of
these packages uploaded to experimental to pick up the new name. The intent
is to work with the ftp team to batch-accept these through binary NEW once
all of the uploads are done, and then promptly proceed with upgrades to
experimental.
Do you have a different suggestion?
Note that even including a versioned build-dependency on dpkg-dev in the
uploads to experimental doesn't really address the possibility of ABI skew
if reverse-dependencies are uploaded during the critical window where dpkg
has not yet been uploaded to unstable, because *those* packages will not
have a versioned build-dependency on dpkg: so will link against the
libraries with the new names but will themselves be using the old ABI.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
