Re: Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code
On Sun, Jun 16, 2024 at 03:43:38PM +0100, Julian Gilbey wrote: > * Package name: requests-mock > Version : 1.12.1 > Upstream Author : Jamie Lennox > * URL : https://github.com/jamielennox/requests-mock > * License : Apache-2.0 > Programming Lang: Python > Description : Python module to stub HTTP requests in testing code > This module creates a custom adapter that allows one to predefine responses > when certain URIs are called when using the `requests` module. Is this something different then the already exising python-requests-mock? Package: python-requests-mock Binary: python-requests-mock-doc, python3-requests-mock Version: 1.9.3-2 Maintainer: Debian OpenStack Uploaders: Thomas Goirand , Corey Bryant , Build-Depends: debhelper-compat (= 10), dh-python, openstack-pkg-tools (>= 99~), python3-all, python3-pbr, python3-setuptools, python3-sphinx Build-Depends-Indep: python3-fixtures, python3-mock, python3-purl, python3-pytest, python3-requests, python3-six, python3-subunit, python3-testtools, python3-urllib3, subunit, testrepository Architecture: all Standards-Version: 4.1.3 Format: 3.0 (quilt) Files: f7225288c06649b675170c22915d9b2d 2508 python-requests-mock_1.9.3-2.dsc 08d0deaba073d0a3b78a48581589b7e9 0 python-requests-mock_1.9.3.orig.tar.xz 6f33e9c63b0e3c2b8dca12df1ccf78ad 4036 python-requests-mock_1.9.3-2.debian.tar.xz Vcs-Browser: https://salsa.debian.org/openstack-team/python/python-requests-mock Vcs-Git: https://salsa.debian.org/openstack-team/python/python-requests-mock.git Checksums-Sha256: da5bb07468737f7e1ce81fdb5729de364b5c93c363e6a88ce12011a4137da7cb 2508 python-requests-mock_1.9.3-2.dsc 8e48436f450a313cc360736dab7d1b08ad22e7c0e49c48247b3679eca7e72b04 0 python-requests-mock_1.9.3.orig.tar.xz c199ac19ba8b9a6d0380b1feb5d640db4fdcfdd9add386bbb8712d62bdaadfc0 4036 python-requests-mock_1.9.3-2.debian.tar.xz Homepage: https://github.com/jamielennox/requests-mock Package-List: python-requests-mock-doc deb doc optional arch=all python3-requests-mock deb python optional arch=all Testsuite: autopkgtest-pkg-python Directory: pool/main/p/python-requests-mock Priority: optional Section: misc -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3
Re: MBF: Building packages in the (not so distant) future
On Sun, May 26, 2024 at 05:43:54PM +, Scott Kitterman wrote: > On May 26, 2024 5:35:27 PM UTC, Santiago Vila wrote: > >https://people.debian.org/~sanvila/build-logs/trixie-time-bomb/ > The clamav issue looks like a false positive. The distro-info data will get > updated between now and then. I see this failure: | Test that clam can trust an EXE based on an authenticode certificate check. This clearly sounds like an expiration date somewhere, esp as this looks like a shipped binary. So, you where talking about developers-reference. However I don't see how a probable update of distro-info would make this a false positive. In fact, it is an explicit time bomb. Bastian -- No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7
Re: finally end single-person maintainership
On Tue, Apr 09, 2024 at 06:37:23PM +, Holger Levsen wrote: > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. We still like those VCS-in-VCS workflows over everything else. Those debian/patches, where you need to call something special and can't just re-use upstreams CI tests. And which conflict outside of git with the next upstream version. I just stopped that and use git alone. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. What would that even mean? What is a team anyway? Bastian -- Beam me up, Scotty, there's no intelligent life down here!
Re: Validating tarballs against git repositories
On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote: > On 2024-04-01 12:44, Bastian Blank wrote: > > So in the end you still need to manually review all the stuff that the > > tarball contains extra to the git. And for that I don't see that it > > actually gives some helping hands and makes it easier. > > > > So I really don't see how this makes the problem in hand any better. > > Again the workload of review is on the person doing the job. Aka we do > > fragile manual work instead of possibly failing automatic work. > > I think that if Debian was using git instead of the generated tarball, this > part of the backdoor would have just been included in the git repository as > well. If we were able to magically switch everything to git (and we won't, > we are not even able to agree on simpler stuff), I don't think it would have > prevented the attack. Nothing prevents such an attack. Prevent would be a 100% fix, which can not exist. However what we can do is to make it harder to pull off. If they had been forced to commit all the activation code into the repo, it would have been directly visible for everyone. But instead, they choose to only ship it in the tarballs. That's why I asked if this would make it better, by removing this manual review task from the maintainer. Bastian -- I object to intellect without discipline; I object to power without constructive purpose. -- Spock, "The Squire of Gothos", stardate 2124.5
Re: xz backdoor
Hi On Mon, Apr 01, 2024 at 12:40:51PM +0200, Ansgar 🙀 wrote: > For OpenSSH it might also be more convenient to use Webauthn, that is, > the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`. Also those key types allow two different uses. Persistent or non-persistent keys differ in where parts of the key is stored and protected. Persistent keys store the second part on the hardware itself. So you can extract that part if you know the PIN of the hardware. I for example have one for access to my emails and irc system. Non-persistent keys store the second part on the using system, aka your hard drive. Those files can optionally be protected with a standard SSH passphrase. You can also have many different keys this way. But please be aware: resetting the fido part of a yubikey is pretty easy and will immediatelly make all keys unusable. Bastian -- Punishment becomes ineffective after a certain point. Men become insensitive. -- Eneg, "Patterns of Force", stardate 2534.7
Re: Validating tarballs against git repositories
On Mon, Apr 01, 2024 at 12:03:48PM +0200, Bastian Blank wrote: > On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote: > > That's not mutually exclusive. When adding an additional git remote > > and using gbp-import-orig's --upstream-vcs-tag you get the best of > > both worlds. > And this will error out if there are unexpected changes in the tarball? > How will it be able to detect those? Okay, I looked into what it does. It just adds another parent to the commit with the import of the tar. It does nothing else with this information. So in the end you still need to manually review all the stuff that the tarball contains extra to the git. And for that I don't see that it actually gives some helping hands and makes it easier. So I really don't see how this makes the problem in hand any better. Again the workload of review is on the person doing the job. Aka we do fragile manual work instead of possibly failing automatic work. Bastian -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9.
Re: Validating tarballs against git repositories
On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote: > That's not mutually exclusive. When adding an additional git remote > and using gbp-import-orig's --upstream-vcs-tag you get the best of > both worlds. And this will error out if there are unexpected changes in the tarball? How will it be able to detect those? Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0
Re: xz backdoor
Hi On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote: > > What we can do unilaterally is to disallow vendoring those files. > These files are supposed to be vendored in release tarballs, > the sane approach for getting rid of such vendored files would > be to discourage tarball uploads to the archive and encourage > git uploads instead. I don't understand what you are trying to say. If we add a hard check to lintian for m4/*, set it to auto-reject, then it is fully irrelevant if the upload is a tarball or git. > > Does it help? At least in the case of autoconf it removes one common > > source of hard to read files. > But I doubt every DD would be able to review the 2k LOC non-vendored > autoconf code in xz. But at least changes to this code are visible. In this case the changes to the m4 stuff did not exist in the somewhat reviewed repo, but just in the unreviewed tarballs. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Re: xz backdoor
On Sun, Mar 31, 2024 at 11:59:35AM +0100, Colin Watson wrote: > > What we can do unilaterally is to disallow vendoring those files. > > Does it help? At least in the case of autoconf it removes one common > > source of hard to read files. > That's doable unilaterally to some extent, using the dh-autoreconf style > of approach: the files may be vendored in the upstream tarball, but > we'll throw them away and rebuild them. No, I don't think that this is adequat. There are too many ways they could still be used accidentaly or on purpose. The only way to make sure it is never used, is to remove it all. In other words: dh-autoreconf fails open: if something happens it will just use the vendored stuff. Nuking the files fails close: if something happens it will just not work at all. > I did that recently for the > packages that use gnulib where I'm upstream (e.g. > https://salsa.debian.org/debian/libpipeline/-/commit/b596eefb342e93136cf1f479415981fc7f48). > Frankly, I suspect that it will introduce slightly more FTBFS bugs over > time due to differences between the packaged version of gnulib and the > version in use upstream (although things have got better in that regard > over the last year or so with the introduction of stable branches), but > it does seem to be worth it for transparency. Thanks about this first step. But shipping dead code is not defence in depth. It will just produce another completely unaudited pool of hard to read code. Bastian -- If a man had a child who'd gone anti-social, killed perhaps, he'd still tend to protect that child. -- McCoy, "The Ultimate Computer", stardate 4731.3
Re: xz backdoor
On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote: > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote: > > I have seen discussion about shifting away from the whole auto(re)conf > > tooling to CMake or Meson with there being a reasonable drawback to CMake. > > Is that something being discussed within Debian as well? > It's not in general something that Debian can unilaterally change. And > in a number of cases switching build system would be pretty non-trivial. What we can do unilaterally is to disallow vendoring those files. Does it help? At least in the case of autoconf it removes one common source of hard to read files. Bastian -- Vulcans do not approve of violence. -- Spock, "Journey to Babel", stardate 3842.4
Re: xz backdoor
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. So an attacker needs to wait until you ask the HSM it is okay to sign something. Bastian -- War isn't a good life, but it's life. -- Kirk, "A Private Little War", stardate 4211.8
Re: xz backdoor
On Sat, Mar 30, 2024 at 07:15:28PM -0700, Otto Kekäläinen wrote: > I am doing all my builds inside a (Podman) container with the sources > loop-mounted. You do, but Debian itself (aka DSA) does not. They still prefer to trust all 100k packages and run them as root in the init namespace over the five people who can login as buildd and potentially trigger capability reachable problems in the kernel. This is what got as in part of the situation, as we don't even know if the buildd hosts are untampered. Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
Re: Validating tarballs against git repositories
On Sat, Mar 30, 2024 at 01:30:07PM +0100, Jan-Benedict Glaw wrote: > On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci wrote: > > On 30/03/24 01:21, Antonio Russo wrote: > > > 3. Have tooling that automatically checks the sanitized sources against > > > the development RCSs. > > git-buildpackage and pristine-tar can be used for that. > Would be nice if pristine-tar's data file would be reproducible, > too... Use pristine-lfs. Or just generate via "git archive". Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7
Re: Limited security support for Go/Rust? Re ssh3
On Wed, Jan 24, 2024 at 11:40:20PM +, Wookey wrote: > If it only done for security issues, rather than routinely, then that > shouldn't be that much extra load (does anyone have any idea how much > extra building we are talking about? Is it trivial, or huge?) If we do those rebuilds in stable security we have several bottlenecks: - We need to get all the other packages into security, need some way to trigger rebuilds (I still think we need to kill the current way of BinNMU alltogether) - Those can only build after the fixed package was released (or at least completely built) - DSA are supposed to be available for all updates, so we now need to list hundred of packages. - The separate security archive is severely space limited. - SRM like to look at all updates as well. Bastian -- Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, "The Conscience of the King", stardate 2818.9
Re: Limited security support for Go/Rust? Re ssh3
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. > 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? Bastian -- Many Myths are based on truth -- Spock, "The Way to Eden", stardate 5832.3
Re: Limited security support for Go/Rust? Re ssh3
On Tue, Jan 16, 2024 at 11:22:48AM +0100, Jérémy Lal wrote: > I naively believed that golang-* packages expressed those dependencies with > "Built-Using". 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 Bastian -- "Life and death are seldom logical." "But attaining a desired goal always is." -- McCoy and Spock, "The Galileo Seven", stardate 2821.7
Re: Limited security support for Go/Rust? Re ssh3
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. Please show practical problems with it? The result of autoconf and automake is not embedded into the produced binaries, so a security vulnerability can not go on. 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. > The problem with dependencies are more obvious for Go/Rust code but I > think we always have had that problem anyway. Here the problem is embedded into the language oekosystem itself. It is not a choice of the software author to do static linking. > 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. I asked for practical solutions, not theoretical ones. We don't have a suitable way to rebuild all packages just because right now. > Maybe I'm missing how these two problems result in different problems > for the security team? You did not show that autoconf/automak/gnulib is a problem at all. And a => b with a false gives no answer. Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3
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. So this is an accademic project. I would question that it actually solves the same problem as SSH does. The paper might also be missleading. They compare session setup time, but don't even describe the used parameters. They don't describe a way to use real authentication, instead they just refer to HTTP, which does not specify anything equivalent to what SSH uses by default. > - Significantly faster session establishment Questionable. > - New HTTP authentication methods such as OAuth 2.0 and OpenID Connect > in addition to classical SSH authentication In addition? I don't see any way to use authentication similar to SSH in this. But maybe just show where I can use sk-ssh-ed25...@openssh.com authentication, which is a modern one, with this. > - Robustness to port scanning attacks: your SSH3 server can be made > invisible to other Internet users You still have a HTTP listener that can be seen. Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Re: Limited security support for Go/Rust? Re ssh3
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? Bastian -- A father doesn't destroy his children. -- Lt. Carolyn Palamas, "Who Mourns for Adonais?", stardate 3468.1.
Re: Ability to further support 32bit architectures
On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote: > > As it is now, we will not be able to provide a kernel for maybe all > > 32bit architectures for Trixie. > I don't think that this would be a reasonable decision. We're preparing to > switch > 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would > make > this whole work moot. This is completely unrelated. Userland != kernel. And people already talked about only supporting userland for those architectures. > FWIW, both m68k and powerpc are not affected by this bug, the powerpc build > fails > because of a packaging problem. Actually powerpc fails for exactly the same reason: | cc1: out of memory allocating 135266296 bytes after a total of 244908032 bytes | make[9]: *** [/<>/scripts/Makefile.build:248: drivers/media/pci/solo6x10/solo6x10-p2m.o] Error 1 https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.7-1%7Eexp1&stamp=1704796355&raw=0 Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: Ability to further support 32bit architectures
Hi On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote: > Disabling debug symbols, enabling debug symbol zstd compression, using > split debug symbols (disabled BTF usage) should help here. Okay, maybe more workarounds exist. But none of them look really promising. > Separately, I wish we had cross-builders available, and cross-build > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit > compiler. Real cross-builders would use some fast amd64/arm64/ppc64el (and for amd64 also reasonably cheap) machines to build all other architectures. Bastian -- You're dead, Jim. -- McCoy, "Amok Time", stardate 3372.7
Ability to further support 32bit architectures
Hi Linux 6.7 fails to build on at least i386 and armhf. Even it now manages to make the compiler fail to allocate memory: | cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes Right now both fail on the same driver, so a short team workaround would be to disable it. But we need a long term fix, and quickly. As it is now, we will not be able to provide a kernel for maybe all 32bit architectures for Trixie. Bastian -- No one can guarantee the actions of another. -- Spock, "Day of the Dove", stardate unknown
Re: Signature strength of .dsc
On Fri, Dec 01, 2023 at 12:20:16AM +, Dimitri John Ledkov wrote: > And many of them cannot be verified using debian-keyring: > 2,455 no public key > 3 wrong key usage And how many can be verified? Do any show broken signatures? > Should we stop requiring signed .dsc on uploads? We had exactly that discussion some years ago in those two tag2upload thread. Maybe you should re-read that. Why do you believe that 0% is better then 90%? Bastian -- All your people must learn before you can reach for the stars. -- Kirk, "The Gamesters of Triskelion", stardate 3259.2
Re: Clarification for broken packages in IPv6-only environments
On Thu, Nov 30, 2023 at 08:24:18PM +0100, Thomas Braun wrote: > Now I would like to know if being able to run in an IPv6-only environment is > a must have feature for any debian package? As Debian uses package builders in this configuration, packages needs to build in such an environment. Bastian -- Captain's Log, star date 21:34.5...
Re: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')
On Sat, Nov 25, 2023 at 10:30:39AM +0100, Bastian Blank wrote: > Thank you for purposefully not mentioning that this only applies if you > use the bothed(?) gcc spec override to build with musl instead of glibc. > Can you show it is broken if using the standard toolchain as asked > by the maintainer? And of course, only musl-gcc is affected. | % mips64el-linux-gnuabi64-gcc -specs /usr/lib/mips64el-linux-musl/musl-gcc.specs | mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option ‘-EL’ | mips64el-linux-gnuabi64-gcc: fatal error: no input files | compilation terminated. | % mips64el-linux-gnuabi64-gcc | mips64el-linux-gnuabi64-gcc: fatal error: no input files | compilation terminated. Now, what is the problem? Well, the spec removes the knowledge about the -EL and -EB arguments by overriding *cc1. So the fix is to re-add those arguments: | %rename cc1 old_cc1 | *cc1: | %(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s %(old_cc1) Bastian -- Our way is peace. -- Septimus, the Son Worshiper, "Bread and Circuses", stardate 4040.7.
Re: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')
Hi Thorsten On Fri, Nov 24, 2023 at 06:58:40PM +, Thorsten Glaser wrote: > Matthias Klose dixit: > >, this is not an RC issue. Please stop playing > > bug ping pong. > > If GCC stops supporting an option it used to support, > and where the GCC documentation say it’s supported, > it in my opinion very much is an RC bug. Thank you for purposefully not mentioning that this only applies if you use the bothed(?) gcc spec override to build with musl instead of glibc. Can you show it is broken if using the standard toolchain as asked by the maintainer? The gcc spec also defines which arguments are supported. So if your spec override does not support a particular one, then it will not work. However what I now find interesting is: the Debian gcc 12 on amd64 got the options -muclibc, -mbionic amd -mmusl for some limited support for those alternative libc. Bastian -- I'm frequently appalled by the low regard you Earthmen have for life. -- Spock, "The Galileo Seven", stardate 2822.3
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote: > >>>>> "Bastian" == Bastian Blank writes: > Bastian> Why do we need to have the priority adjusted instead of fix > Bastian> d-i to install what it knows the user needs? > Because it's not just D-I, it's bootstrapping in general. > For that reason I support raising the priority. No, it isn't. Bootstrapping does not magically enable ifupdown to do dhcp, this requires explicit config, as done by d-i. And you can expect the tool doing the config to make sure the appropriate packages are installed. Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón wrote: > For the moment, ifupdown is still installed by the debian-installer as > default network interfaces manager. And after sleeping over it, and > discussing with debian fellows, I would like to call for consensus to > rise Priority: Important to dhcpcd-base (as initially requested in > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. Why do we need to have the priority adjusted instead of fix d-i to install what it knows the user needs? Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1
Re: Policy consensus on transition when removing initscripts.
On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote: > It's not. As written by Russ in this thread, filling a bug against > orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't > mind seeing this mandatory, and written in the policy. I do. This also does not have anything to do with how packages look or work. This is about non-technical interaction, so at most should be part of the developers reference. But this still bears the question why this needs manual work and in doing this distribute the work away to other people. Bastian -- We fight only when there is no other choice. We prefer the ways of peaceful contact. -- Kirk, "Spectre of the Gun", stardate 4385.3
Re: Policy consensus on transition when removing initscripts.
On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote: > > Less prone to errors than a manual process might be to watch > > automatically where legacy startup scripts disappear anyway; it's not > > that complicated to do. People tend to forget things. > > That sounds reasonable. It might be sufficient for the policy discussion to > say > that maintainers who drop sysv init scripts should file a bug against orphan- > sysvinit-scripts with the final version of the provided init attached and > which > lists the lowest version that won't include it (so that orphan-sysvinit- > scripts can Replaces << that version). Automatically is clearly not the same as "file a bug". It is not a useful way to ask hundreds of people to do things if you can do it on your own. Bastian -- Military secrets are the most fleeting of all. -- Spock, "The Enterprise Incident", stardate 5027.4
Re: Policy consensus on transition when removing initscripts.
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote: > To avoid breakage of existing systems and facilitate ongoing support for > non-systemd inits, I would like to establish a consensus for > - stating that initscripts remain useful. > - requiring a coordinated transition of any initscript a maintainer wishes to >drop to the orphan-sysvinit-scripts package and providing the relevant >copyright information. Sorry no. Please add a conversion layer that adopts service and maybe other systemd units to initrc if you care about it. This is what systemd does to adopt existing init scripts, so you can do the opposite. And it can detect easily if no init script exists for a given unit, so no coordination necessary. Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, "Obsession", stardate 3620.7
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jun 22, 2023 at 08:51:01PM +0200, Philipp Kern wrote: > TBH time is too short to manually provision IP addresses on servers. And DHCP is gladly enough entirely optional since SLAAC exists. But for that you need systemd-networkd/systemd-resolved or a whole bunch of other software. Bastian -- "... freedom ... is a worship word..." "It is our worship word too." -- Cloud William and Kirk, "The Omega Glory", stardate unknown
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Fri, Jun 09, 2023 at 12:25:21PM +0800, Paul Wise wrote: > Has anyone checked what percentage of these binaries will still run > adequately after 2038 with 32-bit time_t? All, because you don't need to provide those programs with a correct time. But this is all a positive decisions. > Presumably any network components will be dead or require modern > protocols by then, so this could only be offline programs? What difference does this make? Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote: > On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote: > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > > modern x86_64 systems > > 2a. legacy native Linux i386 binaries > > 2b. legacy Windows i386 binaries via Wine (which requires a somewhat > > complete i386 Linux library stack) > Would it be feasible to drop i386 but still support this use-case by > requiring folks to use historical releases on archive.debian.org? No. One package for different architectures is only co-installable if they have the same version. Bastian -- Conquest is easy. Control is not. -- Kirk, "Mirror, Mirror", stardate unknown
Re: Dynamic linker support for FPC.
On Sun, May 28, 2023 at 08:27:16PM +0200, Ansgar wrote: > I think this entry from the changelog is meant: > > +--- > | 2020-02-15 Florian Weimer > | > | COMMIT: 3a0ecccb599a6b1ad4b149dc569c0080e92d057b > | ld.so: Do not export free/calloc/malloc/realloc functions [BZ > #25486] > +--- > > Which is an incompatible ABI change. ld.so is not a library. For various reasons it technically is a shared object and also can export symbols (which is used to share stuff between glibc and it's interpreter). But it is not a library and you need to properly link with libc.so for any implementation stuff. ld.so contains it's own minimal malloc and friends implementation, which is now incompatible with the one in libc.so itself. In the end this a bug in FPC, which tries to link to ld.so, which is broken. See https://sourceware.org/bugzilla/show_bug.cgi?id=25486 for the glory details. And also there is no way to do a transition for it without moving every binary built on Debian on a private ABI. Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi Steve On Mon, May 15, 2023 at 02:01:15AM +0100, Steve McIntyre wrote: > Russ has described copying *binaries* out of packages and running them > elsewhere. I've done that too, from time to time. This is one of the > things made possible by the ABI contract being followed. And nothing in that requires that the interpreter matches. Because glibc is clever enough to allow running the interpreter standalone. So in any way you can just call: /lib64/ld-linux-x86-64.so.2 /bin/ls Bastian -- Oh, that sound of male ego. You travel halfway across the galaxy and it's still the same song. -- Eve McHuron, "Mudd's Women", stardate 1330.1
Re: setting sysctl net.ipv4.ping_group_range
On Sun, Jan 15, 2023 at 02:35:06AM +0100, Ángel wrote: > I would change that to: Please don't. If we change the distribution default for net.ipv4.ping_group_range, then ping should refrain from ever trying to check for it and never make the executable privileged. Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
Re: SONAME bumps (transitions) always via experimental
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote: > Once accepted, > the proposed workflow should also become documented in Debian policy. As this is no technical policy, this belongs into the developers reference. However, please describe an actionable plan. What do you want to be rejected, in a codified form. It would be nice if you could provide a patch for process-new that displays this information. Bastian -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9.
Re: Populating non-free firmware?
On Sat, Dec 24, 2022 at 11:44:49AM +0200, Jonathan Carter wrote: > Will the archive team be moving those over? Is it up to firmware packagers > to re-upload it to the correct component? AFAIK this requires a re-upload. However, does the installer properly include it yet? I need to check that. I can handle the main firmware packages maintained by the kernel team. Bastian -- Captain's Log, star date 21:34.5...
Re: Sunsetting sso.debian.org
On Tue, Oct 18, 2022 at 11:20:10AM +0200, Joerg Jaspert wrote: > Am 2022-10-18 04:52, schrieb Paul Wise: > > > Salsa should be there for git (related) things. > > > NOT as an identity/login provider for Debian Please formally retract the agreement that was forged two years ago then. I properly referenced it already. Until then, it still is an identity provider. > No, it is a bad, not a good thing, to use Salsa for this. > Salsa is a "repository service" with some added nice features related to > them. It is good at that, yay. Fine. No, it is much more then a repository system. > Salsa is really bad as an identity/authentication service. Having a salsa > account does NOT mean ANYTHING related to Debian, like DM/DD/whatever. It is an identity provider, yes. It provides a fixed identity. Further information are optional. Where are they required? >And > thats information that such a service ought to provide too. This is the Debian LDAP. > It also does not > allow any kind of useful management of identities besides "the account is > there/blocked/deleted". And so, as soon as you would want to NOT allow > someone a login to a service that uses salsa as a login service - you need > to delete their account. Including their repositories and abilities there. > Not good. When exactly do you want to do that and how would that work? Bastian -- Women are more easily and more deeply terrified ... generating more sheer horror than the male of the species. -- Spock, "Wolf in the Fold", stardate 3615.4
Re: Sunsetting sso.debian.org
On Sun, Oct 16, 2022 at 07:22:28PM +0200, Enrico Zini wrote: > I'm posting this to debian-devel as an early heads-up and a call for > other maintainers. If nobody steps in my the end of October, I'll post a > proper sunset announce to debian-devel-announce. Everyone coming up with solutions, please review the old thread about that https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org Regards, Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8
Re: Welcome to your new installation of Debian GNU/Linux bookworm/sid
On Sun, Oct 09, 2022 at 09:41:29AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> This breaks a number of setups like:
>
> - the sbuild autopkgtest
>https://salsa.debian.org/debian/sbuild/-/jobs/3353627/raw
> - the dropbear autopkgtest
>
> https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dropbear/26716581/log.gz
> - autopkgtest-virt-qemu image builders
> - the MNT reform image builder
> - the mmdebstrap testsuite which builds a qemu system image for its
>local tests
> - the mmdebstrap jenkins job
This is a bug in mmdebstrap:
| open my $fh, '>', "$options->{root}/etc/machine-id"
| or error "failed to open(): $!";
| print $fh "uninitialized\n";
| close $fh;
Bastian
--
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
Re: Q: uscan with GitHub
On Tue, Sep 20, 2022 at 08:36:48AM +0800, Paul Wise wrote: > On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote: > > Hi, what I usually do with GitHub is to use its API, since it has the > > advantage of not breaking uscan when they do changes to the web UI. > Since the API uses pagination, this has the minor downside of making it > harder to use the uscan --download-version option with older versions. Well, uscan can properly implement pagination. It is just not a simple scraper anymore. Bastian -- It is more rational to sacrifice one life than six. -- Spock, "The Galileo Seven", stardate 2822.3
Re: Clarification regarding zlib1g-dev package for buster-slim s390x
Hi Yasir On Thu, Aug 11, 2022 at 03:14:03PM +, Yasir Ashfaq1 wrote: > Could you please let us know why there is a discrepancy in version of zlib1g > and zlib1g-dev package or whether there is a possibility that you have missed > adding updates for s390x. Debian Buster was moved to LTS state a few days ago. s390x is not a supported architecture by Debian LTS. So no updated packages will be provided. You need to upgrade to a supported release of Debian. Bastian -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Re: Firmware: Scope of non-free-firmware
Moin On Tue, May 10, 2022 at 02:30:04PM -0600, Sam Hartman wrote: > Build Dependencies > == > > As a consequence of options 2-4, non-free-firmware would typically need > to be enabled whenever non-free is enabled. I don't understand why this is the case? Option 2 just needs non-free for building non-free-firmware, not always. Do we have that case that firmware needs non-free tools to build? Do we now have just non-free or also no-source tools to build a firmware, just to avoid shipping the binary of the firmware directly? It is not likely that we could in any way modify such a firmware without access to many other tools and documentation. > Binary Dependencies > === > > It's possible that packages in non-free-firmware could depend on > non-free libraries or downloader tools or whatever. Downloaders can go to contrib already, so we would not need non-free-firmware for that. Bundling firmware and libraries is done only in one case as far as I know: nvidia. > Source Distributions > > > Yet anyone who cares that much about software freedom is likely to care > about distributing complete source for a work including source for > anything it depends on. I usualy would say: they are free to rebuild the media without the firmware on it. > As I understand it, a source package in main can build both binary > packages in main and contrib. It is technically possible, but AFAIK discouraged, as it breaks several assumptions dak and the release team tooling does. > Back to What Goes in Non-free-firmware > == > > I will admit that I find it fairly hard to define what is firmware and > what isn't. I also find it challenging to really defend that boundary > as the boundary we're willing to cross for practical reasons. > Steve did a good job of summarizing how what it is to be firmware has > gotten more complicated over the years. > As a reminder, firmware does sometimes run on the CPU (microcode, UEFI), > sometimes is software, sometimes is more like data. > (And yes, I know that the way in which microcode runs on the CPU is > different than UEFI). Sure, UEFI is a firmware. But in the past we always talked about the firmware stuff that does _not_ run on the main CPU, but on the CPU integrated into other hardware pieces. The same for microcode, it is not stuff running on the main CPU. > * High quality proprietary voices that can improve accessibility for > screen reader users > * Data for input methods that makes input easier for non-English > environments. (I don't know if this is an area where free > alternatives have caught up) > * Machine learning models for speech that would make it easier for > people who cannot easily type to use Debian. I see what you mean. But nothing of that actually enables the use of a particular hardware. > * Proprietary Nvidia graphics drivers. This is explicitly code built and run on the main CPU, not firmware. It also needs firmware running on the device itself. > Personally I think most if not all of the above are in the same category > as firmware at least in terms of how I think about them and software > freedom. Actually they are not in the same category. > I'd rather come up with some rules based on other categories than > firmware vs not. > Perhaps something like non-free-firmware is for packages that make it > possible to use the system or its hardware where there is no free > alternative providing comparable functionality. But then we can't call it firmware. And this definition does not longer fit firmware. Hardware and firmware are a unit, you need both to use it. So it is not "no free alternative", but "integral but separate shipped part of the hardware". Regards, Bastian -- One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4
Re: shim-signed (was: Firmware - what are we going to do about it?)
Moin On Tue, Apr 26, 2022 at 04:14:02PM +0200, Marc Haber wrote: > On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre > wrote: > >We don't have good docs around this in general (hey, it's security > >software - it's against the law to write good and complete docs!), but > >I've certainly discussed this with a few folks over the years. > It would be great to have that written down somewhere to tell poeple > what they're actually doing. Something like https://wiki.debian.org/SecureBoot? > >Alternatively, people can build replacement shim-signed packages using > >their own root of trust if desired. If we had a large enough number of > >users wanting a different root of trust, we could even offer our own > >different shim-signed package to match. > I would probably prefer to have grub an/or the kernel signed, avoiding > additional code, but maybe having some explanation would convince me > that the shim actually improves things additionally to adding > complexity. All the UEFI parts (GRUB, kernel) and also the kernel modules _are_ signed. Otherwise this whole stunt would be kind of useless. However, secure boot signing process at Microsoft is a review-sign process, aka you send the binary to the authority and get a signature back. They don't provide a signed certificate, which you could use to sign stuff at will, as you would do with an e-mail (to be exact, S/MIME and secure boot uses the same signature format). So it is simply not possible with the existing process, to sign everything with it. So shim was introduced, which is signed using the review process, and adapts the signing to accept signatures done by another CA, which is controlled by Debian and used to sign everything. Regards, Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Re: Firmware - what are we going to do about it?
On Tue, Apr 19, 2022 at 12:17:06PM +, Jeremy Stanley wrote: > It's probably what you meant, but just to be clear, as a user I'd > also want to know which of the firmware packages used/installed were > pulled from non-free and what devices prompted their addition. > Something like "The following packages do not meet Debian Free > Software Guidelines but were installed because they're necessary in > order to enable or secure some of your hardware: foo(CPUX21 > processor microcode), bar(PM2743 power management controller), > baz(RF17G wireless interface), ..." Why? Don't you want to use your devices? And will you also remove the flash chips for the ones that contain a backed in firmware (aka all of them)? Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
Re: Keep both images but stop pretending no-free is unofficial
Hi Sam On Tue, Apr 19, 2022 at 02:05:20PM -0600, Sam Hartman wrote: > Marc> Would that not be possible by having an image WITH firmware > Marc> and an installer asking whether the user wants a free or a > Marc> usable system? > For example I would thinki it would be entirely reasonable for someone > to want to include a version of Debian installer for use with qemu in an > environment that needed to be DFSG free. Can you provide us a copy of the request for it? > Similarly, I think it would be reasonable for someone to want to provide > entirely free Debian media along with a libre laptop. Does this exist in the real world? Which hardware would such a system contain? > If providing an image that includes but does not use non-free components > is acceptable for our users, we could save ourselves a lot of time and > complexity by not repacking sources that include non-dfsg components. > We could just not use those components at least when targeting main for > binaries. Sorry, but why can't you stay on topic? We where talking about firmware, not random non-free stuff. Bastian -- No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7
Re: isa-support -- exit strategy?
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote: > SIMDe (or similar approaches) could be used to build variant(s) of the > library that have compile-time emulation of SIMD instructions in the > lower baseline builds of vectorscan. But why? Who in their right mind would ever try to use those aweful slow implementations? Bastian -- I have never understood the female capacity to avoid a direct answer to any question. -- Spock, "This Side of Paradise", stardate 3417.3
Re: proposed MBF: packages still using source format 1.0
On Wed, Mar 09, 2022 at 01:08:59PM +0100, Lucas Nussbaum wrote: > can we find a middleground where the git workflows don't require staying > with 1.0? Even if that means switching to 3.0 (quilt) using the > single-debian-patch approach? Well. There is a specific source format now for full git workflows: 3.0 (gitarchive). It is implemented outside of dpkg in it's own package dpkg-source-gitarchive. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Re: Q: systemd-timer vs cron
On Sun, Mar 13, 2022 at 11:06:46AM +0100, Marc Haber wrote: > The anti-systemd faction in Debian is cordially invited to step in, > bring cron and cronie up to shape, before asking the rest of the > Distribution to stick with essential system software that has been > unmaintained for years. And in that case, they please generate cron files from systemd timer units. Bastian -- Warp 7 -- It's a law we can live with.
Re: Gmail bounce unauthenticated @debian.org addresses
Hi On Fri, Mar 04, 2022 at 03:15:59PM +0100, Baptiste Beauplat wrote: > Am I mistaken in thinking that's only a case of simply rejecting > unsigned DKIM email? This might be, but… > Return-Path: > Received: from mentors.debian.net (localhost [127.0.0.1]) > by wv-debian-mentors1.wavecloud.de (Postfix) with ESMTP id 55D16823EC > for <**@gmail.com>; Fri, 4 Mar 2022 03:14:03 + (UTC) > Content-Type: text/plain; charset="utf-8" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Subject: Next step: Confirm your email address > From: mentors.debian.net > To: **@gmail.com > Date: Fri, 04 Mar 2022 03:14:03 - > Message-ID: <164636364329.4074035.11224505717463252...@mentors.debian.net> I don't see anything about debian.org in those headers? Do you? - mentors.debian.net is not debian.org. - gmail.com clearly isn't. Bastian -- "That unit is a woman." "A mass of conflicting impulses." -- Spock and Nomad, "The Changeling", stardate 3541.9
Re: Gmail bounce unauthenticated @debian.org addresses
On Fri, Mar 04, 2022 at 12:38:02PM +0100, Baptiste Beauplat wrote: > We recently discovered that Gmail started to bounce email from > mentors.debian.net with the following message: Can you please share the complete headers of the bounced message? Aka the thing in the message/rfc822 part of the DSN message. Right now we don't know what they see from your explanation. Bastian -- A woman should have compassion. -- Kirk, "Catspaw", stardate 3018.2
Re: Is removing smell from packages OK? (Was: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883")
Hi On Fri, Feb 25, 2022 at 09:50:18AM +0100, Jonas Smedegaard wrote: > I would certainly be frustrated if someone fast-tracked an NMU with > structural changes like switching to short-form dh, with the reasoning > that "the packaged had a smell to it", for a package that I maintain. Well, do you ignore RC bugs for a long time? Do you not respond at all the same way? xdelta3 was not uploaded for six years. So you can somehow say it was abandoned. Bastian -- Our way is peace. -- Septimus, the Son Worshiper, "Bread and Circuses", stardate 4040.7.
Re: Cloud team plans for cloud-hosted mirrors
Hi Julien On Wed, Jan 26, 2022 at 07:58:23PM +0100, Julien Cristau wrote: > I think we (DSA) have been reluctant to add new third-party-run services > under debian.org, Just being curious: what is your definition of "third-party-run"? As example: deb.debian.org. It uses Fastly, which is shared responsibility. It is run by someone else but provides a product that Debian configures. But where would be the limit? > and it's not clear to me if that infrastructure would > be run by the cloud team on behalf of debian, or if the cloud team would > control the names but point them at mirrors run by the cloud providers > themselves. I doubt that there will be any reason for us to point Debian names to mirrors the provider controls. There is one provider providing it's own mirrors: Hetzner. They use an already existing mechanism to configure the mirror to their own if not overriden by the user. So there is no name controlled by Debian required. The whole reason for this stunt is to protect Debian. Protect Debian and it's users from screwups by - the providers themselves, - a laps in the agreement that currently provides access to Debian mirrors on Azure and AWS and - single Debian developers controlling resources. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0
Re: Cloud team plans for cloud-hosted mirrors
Hi Marc On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote: > Are the IP ranges of the Cloud Providers registered that badly that > deb.debian.org wouldn't reliably point to the mirrors inside the > provider's infrastructure? Or are the cloud providers' mirrors > differnet from what we expect from a Debian mirror? I wonder, which mechanism would you propose to do so? Bastian -- Witch! Witch! They'll burn ya! -- Hag, "Tomorrow is Yesterday", stardate unknown
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thu, Dec 30, 2021 at 09:19:35PM +0100, Marco d'Itri wrote: > systemd-resolved is supposed to forward queries to the upstream resolver > and always be available on 127.0.0.53, so what does actually change in > resolve.conf when using it? Only if you are using the stub resolver. systemd-resolved can also update a resolv.conf with the real resolver. Okay, you loose a lot of flexibility then, because resolv.conf can't redirect domains to different name servers, but you can do that. Bastian -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, "The Omega Glory", stardate unknown
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thu, Dec 30, 2021 at 08:26:07AM -0500, Scott Kitterman wrote: > > Maybe you should stop supporting the non-standard chroot configuration? > What do you mean by non-standard? It's true that the upstream default is now > not in the chroot, but it's totally a configuration supported by upstream. chroot is non-standard configuration in Postfix and was discuoraged for a lot of years before that. Exactly because of problems like that. > How would you suggest handling upgrades? I've no idea how to determine if an > installation is chrooted because the administrator wanted it chrooted or if > it's merely because that's been the default in Debian for over 20 years. You error out if postconf -M show chroot enabled. > I believe I can solve this problem by adding Recommends: resolvconf if that's > the only way. I had hoped there would be some "modern" way to do it from > within Debian's default package set. No, it can't be solved this way, as resolvconf and systemd-resolved do not communicate. Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thu, Dec 30, 2021 at 01:48:49AM +, Scott Kitterman wrote: > It does. My question is on the other end of the problem. Once resolv.conf > is updated, how do I trigger an action for another package? In this case > it's copy the updated resolv.conf into the chroot and restart postfix. I > know how to do everything except for the trigger. Maybe you should stop supporting the non-standard chroot configuration? Bastian -- "... freedom ... is a worship word..." "It is our worship word too." -- Cloud William and Kirk, "The Omega Glory", stardate unknown
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Wed, Dec 29, 2021 at 04:35:22PM -0500, Scott Kitterman wrote: > The postfix package ships a script in /etc/resolvconf/update-libc.d/ to > restart > postfix when resolv.conf is updated. As far as I know, that still works if > the > resolvconf package is installed, but if not (i.e. Debian default), what's the > equivalent? Does systemd-resolved have an equivalent? Should users that > want > this functionality install resolvconf? Why do you need to restart services on resolv.conf changes? The libc resolver takes care of it by re-reading the file after it changed. Bastian -- Actual war is a very messy business. Very, very messy business. -- Kirk, "A Taste of Armageddon", stardate 3193.0
Re: ungoogled-chromium?
On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote: > Same here. And they are now following security updates closely (in the > past, there could lag two or three weeks behind). Flatpak compiles it > from source (while UngoogledChromium let contributors compile it and > publish the binary because GitHub CI does not allow such resource-heavy > build). You mean th builds of the Flatpk stuff are not properly controlled? But instead uncontrolled done by contributors? Bastian -- There are some things worth dying for. -- Kirk, "Errand of Mercy", stardate 3201.7
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote: > Some stupid questions that I couldn't answer by reading the man page > or doing a quick google search > * How does ld.so --preload *work*? ld.so is the ELF interpreter. If you run a normal binary, the kernel rewrites this request to load and execute /lib64/ld-linux-x86-64.so.2 instead. This interpreter then loads the real binary, the libraries and jumps to the real code. If you run ld.so directly, that kernel redirection is just not done. The rest of it's tasks however are done just as usual. --preload is just as if the interpreter would see LD_PRELOAD set. > * Does it modify /bin/ls, so that all users running /bin/ls get the > preloaded library? No, preload does not modify binary files, just the loaded binary in memory. > * Does it modify something in the user's home directory? No. > * How do you undo the effects ld.so --preload? You just don't use ld.so and don't set LD_PRELOAD. Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Fri, Dec 03, 2021 at 04:16:04PM +0200, Timo Lindfors wrote: > Just a random thought: If you have configured a restricted shell (e.g. > rbash) that only lets you execute commands in PATH, will this make it > possible to bypass the restriction with "ld.so /tmp/some-random-binary"? > This is not necessary an argument to not do this, I'm just wondering what > the implications could be. The same as /bin/bash -c, /usr/bin/python3 -c. ld.so is an interpreter in the same way. Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote: > Right, thanks for providing a concrete example. A (somewhat) portable > version would look like this: > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl You mean ld.so --preload libeatmydata.so.1.3.0 /bin/ls ? ld.so is able to find the correct path itself. So only looking up the correct ld.so implementation would be needed. Bastian -- Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
Re: Help porting Ceph 16.2.6 to mips6el, mipsel and armel
On Sat, Nov 20, 2021 at 11:31:04AM +0100, Thomas Goirand wrote: > What worries me the most is mips6el, where the linker says "undefined > reference to `__atomic_load_16'" (and more like this). I don't > understand because there really is a -latomic parameter to GCC when > linking, so it should be working. Not all architectures support sub-wordsize atomic operations. The only way to fix that is to use a larger type (long usually). Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Re: [RFC] changes to rsyslog
On Sat, Nov 13, 2021 at 04:40:04PM -0500, Roberto C. Sánchez wrote: > I'm not sure if this a directly relevant question (apologies if it is > not), but is there migration path to allow bringing legacy log data > *into* the systemd journal[*] to allow for accessing log data through a > single interface/mechanism after making the transition? As the automatic cleanup will have removed all the data from before the journal change already, what's the point? Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Re: merged-/usr transition: debconf or not?
On Tue, Nov 09, 2021 at 08:19:40PM +0100, Michael Biebl wrote: > I'm worried that by saying that unmerged is still supported in 12, we open a > can of worms and just punt this down to yet another release cycle. No, unmerged will not be supported in 12. Having the ability to create something does not make it supported. > E.g., what exactly does this mean for backports? Stuff from backports is post-release, so requires a merged system. Bastian -- Star Trek Lives!
Errors from TCP connections (was: How to build circular dependant packages in debian)
On Mon, Sep 20, 2021 at 02:11:06AM +, Paul Wise wrote: > Normally one would get "Connection refused" when connecting to a port > that isn't open, "Connection refused" is generated by TCP reset packets. > but at this site one gets "No route to host", as if > there is no network path to reach the host, "No route to host" is generated by an ICMP error. > which is clearly not true > since the HTTP port works. I wasn't aware it is even possible to have > different routing for each TCP port, I guess this is a feature of > OpenStack? No, this is a feature for all destination rewriting solution, sometimes called NAT or load balancing. Or someone used the wrong setting in iptables. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, "The Menagerie", stardate 3012.4
Re: How to build circular dependant packages in debian
On Sat, Sep 18, 2021 at 02:17:59PM +0530, open infra wrote: > How build a package A where it has a circular dependent package B (where > package B is depend on package A). You try not to, at all costs. Bastian -- A woman should have compassion. -- Kirk, "Catspaw", stardate 3018.2
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Sun, Jul 18, 2021 at 11:13:37AM +0200, Marco d'Itri wrote: > On Jul 18, Simon McVittie wrote: > > If a machine's /usr is not in sync with its /etc and /var, then it is likely > > to work incorrectly: at a minimum, asking dpkg which packages and versions > But in my experience (with shared-/usr containers) this works great as > long as everything is aligned to the same major Debian release. So we can just merge it and make it break even less likely? Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3
Re: Debian 11, system.map, DKMS
Hi On Fri, Jul 16, 2021 at 03:08:51PM +0200, Жора Волков wrote: > A DKMS-built kernel module that I have on my system relies on system.map. A > build script for the module parses that file in order to figure out > addresses of certain functions. No normal kernel module requires tinkering with System.map. Kernel modules use exported functions via normal linking and relocation. This is what everyone uses. So if some module uses System.map, it wants to use not exported functions or violate the kernel license. Function addresses are not even part of our ABI, so such modules are not even compatible between different builds of the kernel. Sorry, but why should we support this? > Now, without that file in Debian 11, there is simply no way for my > DKMS-built module to find out the required function's address (unless I > install that gargantuan debug package). So you have a workaround. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
Re: Need help with Multi-Arch in systemd
On Wed, Jul 14, 2021 at 11:59:11AM +0100, Simon McVittie wrote: > It seems like this would also be good for src:linux, where ABI breaks > are often tied to security fixes that should enter the archive ASAP. As security updates are hand approved, accepting by NEW does not help that much. Bastian -- Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown
Re: Need help with Multi-Arch in systemd
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote: > Asking on #debian-systemd, Marco d'Itri suggested, that we move > libsystemd-shared into a separate binary package. This would only help, if > we moved libsystemd-shared into a Multi-Arch location (which means, we'd > have to carry a patch against upstream). It would also mean, that on every > new upstream release, systemd would have to go through NEW. > So I'm not very keen on doing that. Why do you think? libsystemd-shared is a perfectly valid package name and it does not change. However, if you call it libsystemd-shared-249, it is supposed to be stable. Bastian -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Re: Debian Trends updated
Hi Lucas I would like to add: - Removing Berkeley DB. Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4
Re: Bug#986451: ITP: librem-ec-acpi-dkms -- dkms driver sources for EC ACPI in Purism Librem devices
On Tue, Apr 06, 2021 at 12:01:58PM +0200, Jonas Smedegaard wrote: > Description : dkms driver sources for EC ACPI in Purism Librem devices > > The driver librem_ec_acpi provides Linux kernel support > for the ACPI embedded controller of the following devices: > * Purism Librem 14 laptop Why is this support not submitted into the upstream kernel? Bastian -- Not one hundred percent efficient, of course ... but nothing ever is. -- Kirk, "Metamorphosis", stardate 3219.8
Re: RFC: Support for zstd in .deb packages?
Moin On Sun, Jan 10, 2021 at 08:20:33PM +0100, Balint Reczey wrote: > I'm not a fan of CLAs either, but as I understand upstream requiring a > CLA is not a blocker for compression libraries. Well, it means that the library might get incompatible with upstream, because upstream will refuse patches. Bastian -- Dammit Jim, I'm an actor, not a doctor.
Re: Bug#977651: ITP: sphinx-prompt -- Sphinx directive to add unselectable prompt
Hi Christian On Fri, Dec 18, 2020 at 09:56:23AM +0100, Christian Kastner wrote: > Description : Sphinx directive to add unselectable prompt I'm trying to decipher what this (short) description is trying to tell me. "Sphinx directive", okay. "prompt" still okay, however "command line prompt" would be more descriptive. But "unselectable"? I can't interpret that word and according to Merriam-Webster, it does not exist in the english language.[1] I really think you should find something that does not throw of users directly. Regards, Bastian [1]: https://www.merriam-webster.com/dictionary/unselectable -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7
Bug#971692: ITP: openzfs-docs -- OpenZFS Documentation
On Mon, Oct 05, 2020 at 07:52:04AM +, Mo Zhou wrote: > * License : CC-BY-SA I hope you checked that? Example: | % head -n 6 docs/msg/ZFS-8000-14/index.rst | .. |CDDL HEADER START | |The contents of this file are subject to the terms of the |Common Development and Distribution License (the "License"). |You may not use this file except in compliance with the License. > Programming Lang: python Ha ha. Bastian -- Too much of anything, even love, isn't necessarily a good thing. -- Kirk, "The Trouble with Tribbles", stardate 4525.6
Re: DAM Key and identity requirements
Hi Enrico On Sun, Sep 13, 2020 at 09:11:04AM +0200, Enrico Zini (DAM) wrote: > * Minimum key size and acceptable algorithms are actually the domain of >keyring-maint, and we just check those for them. >At the time of writing this, a new key must be larger than 1024bits, >ideally at least 4096bits, and capable of hashes stronger than SHA1. >Please check [KDO] for more recent information. Hmm, this page do not really read like some sort of policy. It talks about key size in bits, which only applies to RSA. What about X25519? > * An encryption subkey must be present, since various parts of our >infrastructure require it. Which parts? While encryption subkeys are useful, I can't see anything _requiring_ this. > * A signature subkey must be there, since various parts of our >infrastructure require it. Also, it is needed to build up trust (see >below). Signing subkeys are pretty rare. What is their use-case? Also trust is built using certification, not signing (the C bit, not the S bit). I don't think subkeys can hold a certification setting. Regards, Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0
Re: Strange build issue on for bart affecting testing migration
On Thu, Sep 17, 2020 at 11:38:46AM +0200, Andreas Tille wrote: > The package has built before and the latest changes are: > Am I > missing something? It built months before, with a lot of other changes surrounding it. E.g. glibc 2.30 vs 2.31. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1
Re: Tagging in Salsa -> upload: status?
On Thu, Aug 20, 2020 at 10:24:18AM +0200, Bernd Zeimetz wrote: > On 8/19/20 7:28 PM, Ansgar wrote: > > Well, I can't fix it without creating dgit-ng (and setting up > > infrastructure for that) as dgit upstream won't accept patches from me. > That is just one of the reasons why I think that salsa should be used > for "official" services like tag2upload. What should Salsa be used for? And what do you mean with "should be used"? Everyone can already setup services running of Salsa projects and integrate using various technics. About tag2upload, there we never left the "how should it work" stage. (Okay, some thing different, but those are the ones proposing a solution without collecting requirements first.) Talking about where it should run might influence the solution, but not overall feature set. Bastian -- Warp 7 -- It's a law we can live with.
Re: Proposal: Allowing access to dmesg for users in group adm
Hi On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote: > 2) Following changes to /bin/dmesg permissions in package 'util-linux' > - Ownership changes to root:adm > - Permissions changed to 0750 (-rwxr-x---) You mean 0754? > - Add cap_syslog capability to binary. Can someone please confirm that filesystem capabilities are restricted to the current user namespace? Otherwise this could allow stuff like containers to read host status. What happens if using capabilities fail? Bastian -- Captain's Log, star date 21:34.5...
Re: Preferred form of modification for binary data used in unit testing?
On Thu, Jul 16, 2020 at 05:27:40PM -0700, Sean Whitton wrote: > On Thu 16 Jul 2020 at 05:19PM -07, Sean Whitton wrote: > > You would need the buggy version of the software if you wanted to > > make modified versions of the binary data to test for closely related > > bugs, for example. And there the problems begin. Every software got bugs and compilers are especially good in finding them. So if you store the software, you can't be sure it will produce the same output over time. Sure, you could store the checksum, which then got the same problem, it is not the preferred form of modification. > It seems that there is not a general answer to the question. The binary > test data may or may not be in its preferred form for modification, > depending on how one would want to go about preparing other pieces of > test data. You are right, it depends. Another data point: our own logo. It is generated using an algorithm. So if someone wants to see it really strict, the algorithm and the parameters would be the source, not the resulting vector image we use all the time. Regards, Bastian -- No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, "Spock's Brain", stardate 5431.6
Re: Preferred form of modification for binary data used in unit testing?
On Thu, Jul 16, 2020 at 08:42:24AM -0700, Sean Whitton wrote: > I would remove the test data because it does not seem DFSG-conformant. Care to explain? You can't claim DFSG violation without showing which part. Also please explain how you would make sure the code is tested. Bastian -- Killing is wrong. -- Losira, "That Which Survives", stardate unknown
Re: Bug#963191: RFH: aufs
Hi Timo On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote: > 20.06.20 13:26 Bastian Blank: > > Since the kernel supports overlayfs since some time now, what blocks > > it's removal? > There are Debian installations on filesystems that are incompatible with > overlayfs, for example xfs without d_type. > I ran into this while trying to get rid of aufs. So we need to document this problem in the release notes. That's an easy task. Regards, Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: Bug#963191: RFH: aufs
Hi Jan On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote: > At the moment aufs is nearly unmaintained since I do not have time due to > personal issues. Therefore, I would be happy if there is somebody to > co-maintain the package. Since the kernel supports overlayfs since some time now, what blocks it's removal? Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Re: Bug#959099: RFP: core-setup -- Helper library for MSbuild .NET Core support
On Wed, Apr 29, 2020 at 02:00:05PM +0300, EoflaOE wrote:
> * Package name: core-setup
core-setup is pretty generic as name. Please rename it to something
more descriptive. I don't now if the dotnet stuff got a naming schema.
Bastian
--
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
Re: Salsa update: no more "-guest" and more
On Tue, Apr 28, 2020 at 02:32:55PM +0200, Bernd Zeimetz wrote: > If you use ssh, you can create an own account for the ssh key and give > it very special permissions, if you need it for automatic pushes or > similar things. Or add it as writable deploy key to a project. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
Re: Salsa update: no more "-guest" and more
On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote: > Actually I think 2FA should be enforced for everybody. No, we don't enforce 2FA for everybody. And I don't consider it appropriate to raise the option. However, you may choose to enforce 2FA for all users of your groups. Regards, Bastian -- It is necessary to have purpose. -- Alice #1, "I, Mudd", stardate 4513.3
Re: Salsa update: no more "-guest" and more
Hi Bernd On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote: > On 4/18/20 11:33 PM, Bastian Blank wrote: > > You are encouraged to use Salsa as an authentication provider for Debian > > services. GitLab supports plain OAuth2 and OpenID Connect as > > authentiation protocols. Every user can register their own applications > > and allow authentication through Salsa. > Could we require 2FA for this please? I'm not sure what you like us to do. Please enlighten us. Regards, Bastian -- Most legends have their basis in facts. -- Kirk, "And The Children Shall Lead", stardate 5029.5
Re: moving mg from salsa to github?
Hi Harald On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > I am maintainer for mg, currently on salsa. Problem is, upstream > doesn't release tar balls anymore, but moved the code to github. This is nothing uncommon. > No tags. So this upstream doesn't make releases but only provides HEAD. > How can I tell Salsa? Salsa is a git hosting. It does not care. > Should I drop the upstream and pristine-tar > branches on Salsa _No_. They refer to Debian releases, not upstream releases. > integrate the repository on github? "Integrate"? > Would > you suggest to move the debian part to github instead? Are you upstream? git is git, regardless of where it is located. Sure, some git hosting services give you additional functionality. But not for this case Regards, Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
Re: Heads up: persistent journal has been enabled in systemd
Hi Scott On Wed, Feb 05, 2020 at 07:44:25AM +, Scott Kitterman wrote: > >> Of course the fact that I can't use all the tools available to > >manipulate text > >> files to follow or analyze logs is problematic. If I'm using > >journalctl, how > >> do I replicate 'tail -f /var/log/mail.loog'? > > > >journalctl -f SYSLOG_IDENTIFIER=2 > > > Do syslog facilities really have to be addressed by number rather than name? > That seems like a horrible interface. That's because you asked a pretty specific question and you've been told the exact replacement. However, you most likely don't actually want to tail this specific file. It is a solution for a more abstract problem, e.g. "I want to see logs from Postfix". And this question got a different answer. Bastian -- War isn't a good life, but it's life. -- Kirk, "A Private Little War", stardate 4211.8
Re: Heads up: persistent journal has been enabled in systemd
On Wed, Feb 05, 2020 at 09:39:19AM +1100, Dmitry Smirnov wrote: > For example, if a certain daemon manifested a condition when a message is > logged too often, then with Rsyslog I could suppress noise by something like > the following This is a workaround for another problem. Fix the real problem. > This is just an example (probably not the best one) how feature can be handy > when it is needed. The point is that you'll only realise that you can't do > something any more is when you need it the most. Please show that one Joey Random User who asked how to do that. > Rsyslog is not broken to be replaced as default logging system. No-one said it is broken. But not broken does not mean a random user needs it. We try to build a distribution with good defaults that fit most people, we don't try to build one that specificaly follows your specific requirements or whishes. > Finally there were no attempt to seek consensus, no survey, nothing? > Just a decision of few maintainers to replace good default with their > preferences? Sure, there was. Please look at debian-vote. > It is difficult to appreciate needless disruptive changes. Which one? Do you really consider persistent journal, which this thread is about, a _disruptive_ change? Please elaborate. Bastian -- "That unit is a woman." "A mass of conflicting impulses." -- Spock and Nomad, "The Changeling", stardate 3541.9
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On Fri, Jan 03, 2020 at 02:29:37PM -0500, The Wanderer wrote: > The accepting of init scripts seemed to me like an essential piece of > making sure those scripts would be present wherever they would be > needed. Your suggestion above seems to provide a way to make it less > essential, and thus would make moving forward easier and more practical. > The only question is how to make sure that that other package would be > present whenever a non-systemd init system is in use, and that seems > like a simple matter of adding dependencies from the > set-foo-as-active-init-system package for foo. Those init-script would life in the package for openrc or sysvinit or whatever you are just working on, because it is implementation to them. Or you use the same systemd-service to own-format conversion, you need anyway for the whole rest, and don't need to implement extra scripts at all. Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On Fri, Jan 03, 2020 at 10:31:53AM -0800, Russ Allbery wrote: > Support for kFreeBSD and Hurd is obviously a valid argument in favor of > some level of support for non-systemd implementations. But then there is the question on how much work it would be to port the **systemd** implementations to FreeBSD or Hurd, if using and maintaining those bash re-implementations is futile. I tried to build systemd-sysusers against the FreeBSD libc, which obviously is not going to be easy. But all the Debian arches use glibc and problems I found where in common, but unused, code and obviously pretty glibc specific stuff. Did someone already try to build just those binaries e.g. on Hurd? Regards, Bastian PS: Why the hack is alloca in alloca.h on glibc, but stdlib.h on BSD? PPS: Yes, systemd uses alloca. -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Sentry for Debian services?
Hi Salsa is a pretty complex beast. As such it got errors. And especially user visible errors. To manage and correlate information about such errors it supports Sentry, which is the de-facto standard to do that work. Sure, the same information can be read from the log, but this is not really usable. I don't think we already have a Sentry instance for Debian services running? Are there other services in need for a Sentry instance? I looked at the install documentation[1] and it tells me that I don't want to run Sentry myself. Any takers? Another option may be using the hosted solution, which they give away gratis to open source projects, which we might be.[2] [1]: https://docs.sentry.io/server/installation/ [2]: https://sentry.io/for/open-source/ -- If there are self-made purgatories, then we all have to live in them. -- Spock, "This Side of Paradise", stardate 3417.7
Re: list of upstream tarball signing schemes?
On Fri, Dec 13, 2019 at 10:55:34AM +0100, Thomas Koch wrote: > I'm packaging nix: https://nixos.org/releases/nix/latest > It releases 3 files: > nix-2.3.1.tar.xz.asc - which signs the .sha256 Why does this not contain a signature of the file itself? The correct filename for this schema would be nix-2.3.1.tar.xz.sha256.asc. > nix-2.3.1.tar.xz.sha256 - which contains the hash of the tarball > nix-2.3.1.tar.xz Regards, Bastian -- You can't evaluate a man by logic alone. -- McCoy, "I, Mudd", stardate 4513.3
Re: TZ=UTC wrong?
Hi Holger On Wed, Oct 30, 2019 at 12:42:54PM +, Holger Levsen wrote: > On Tue, Oct 29, 2019 at 09:00:15PM +0200, Niko Tyni wrote: > > On Mon, Oct 28, 2019 at 12:28:32PM +0100, Guillem Jover wrote: > > > Just noticed this change from the changelog. :) UTC is not really a > > > proper timezone specification, the format requires an offset, so here > > > it would be UTC0 (see «man timezone»). Those are two different concepts. UTC refers to a timezone file, /usr/share/zoneinfo/UTC. There are several files called UTC: | % find /usr/share/zoneinfo -name "UTC*" | /usr/share/zoneinfo/Etc/UTC | /usr/share/zoneinfo/posix/Etc/UTC | /usr/share/zoneinfo/posix/UTC | /usr/share/zoneinfo/right/Etc/UTC | /usr/share/zoneinfo/right/UTC | /usr/share/zoneinfo/UTC UTC0 or UTC+0 defines a unknown timezone called UTC and is 0 hours ahead of the default UTC. Just compare those: | % TZ=UTC+0 date | Mi 30. Okt 12:58:54 UTC 2019 | % TZ=UTC-1 date | Mi 30. Okt 13:58:56 UTC 2019 | % TZ=UTC+1 date | Mi 30. Okt 11:58:58 UTC 2019 Or even: | % TZ=WAT+0 date | Mi 30. Okt 13:00:34 WAT 2019 > What's the opinion of debian-devel@ and others? If you don't want to use the info in the zoneinfo files, specify UTC+0, or DEB+0, or WAT+0. Aren't those localtime maximum and minimum values bogus? The rely on the timezone during build, not during execution. General speaking it is only safe to use values between -2^63+1day and 2^63-1day or so for 64bit time_t anyway. Regards, Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4
Re: [RFC] Proposal for new source format
Hi Russ On Tue, Oct 29, 2019 at 12:19:03PM -0700, Russ Allbery wrote: > Could you help me understand what this would look like? Is it something > like this workflow? > > 1. tag2upload determines the local Git tree that should be uploaded as a >new source package. > > 2. tag2upload locally constructs a source package from that Git tree. > > 3. The uploading user signs the source package that tag2upload constructs. The uploading user signs the .dsc file that was constructed. > 4. tag2upload pushes a rich tag to its upload server that contains enough >information to identify the Git tree that should be uploaded and that >includes the signature over the source package constructed from that >tree. > > 5. The tag2upload server reconstructs the source package from Git, >attaches the signature, and then forwards both to dak. The server reconstructs the source, attaches the signed (by the user) .dsc file and signs the .changes file covering the whole upload itself. > 6. dak validates the signature on the source package and accepts the >package. > > And therefore the goal of this proposal is to define a source package > format that allows this to be done more easily than our current source > package format allows? Yes. Regards, Bastian -- Captain's Log, star date 21:34.5...
Re: [RFC] Proposal for new source format
On Tue, Oct 22, 2019 at 07:33:47AM -0400, Sam Hartman wrote: > My initial reaction is that this is additional complexity in a direction > that we don't need. It is not a question of complexity. It is a question of trust and who we want and need to trust. If we abolish the principle that we want to need little trust as possible and be able to verify all the steps within the archive, then we don't actually need the complexity. But someone needs to stand up and proclamate exactly that. This is what no-one did. It we don't want to do sacrifica that, we have to stick to a chain of trust. > Like Russ, I generally assume that VCS-like things are the future. > I understand there is complexity there. What is "VCS-like"? Please define it. A source package is no VCS, it does not need to be. E.g. dgit is not a VCS-like source package, as it solves a different purpose to a source package we ship in the archive to all our users. Because we are running around this concept for some time now, please help me to actually understand what you mean with it. > But I don't understand why this proposed format would be a step forward > in a world where we care more about VCSes. As an example, I don't > understand how this would make things better for tag2upload. We had that discussion already, it is about the possibility of reproducing the content of the upload. The tag2upload proposal said they can't do it and everyone need to trust this service to do the right thing. I like to solve this problem and allow such a tool/service to forward the trust information by reproducing the output. > I don't think this proposal is sufficiently well developed where you're > going to get much good feedback on debian-devel. What would be the correct location for it? Regards, Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
