Bug#534891: ITP: openssh-known-hosts -- known_hosts downloader for OpenSSH
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: openssh-known-hosts Version: 0.2 Upstream Author: Timo Weingärtner URL: will go to mentors.debian.net as soon as I get the bug number License: GPL2+ Description: This package allows you to download public hostkeys from multiple sources and merge them together into one file for use by OpenSSH. Plugins for some types of sources are included, new plugins can easily be written. signature.asc Description: This is a digitally signed message part.
Re: Bug#534891: ITP: openssh-known-hosts -- known_hosts downloader for OpenSSH
Am Sonntag, 28. Juni 2009 schrieb David Paleino: > On Sun, 28 Jun 2009 01:47:39 +0200, Timo Weingärtner wrote: > > Upstream Author: Timo Weingärtner > > URL: will go to mentors.debian.net as soon as I get the bug > > number > > This should really be upstream URL. I am upstream and there was no public upstream URL at that time. It can now be found at http://mentors.debian.net/debian/pool/main/o/openssh-known-hosts > > Description: This package allows you to download public hostkeys from > > multiple sources and merge them together into one file > > for use by OpenSSH. Plugins for some types of sources are included, new > > plugins can easily be written. > > This should be an appropriate short description, i.e. 60 characters > maximum. What you wrote could well be used for the long description. Actually I used this as the long description, the short description is: "known_hosts downloader for OpenSSH" as in the Subject:. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: Bug#534891: ITP: openssh-known-hosts -- known_hosts downloader for OpenSSH
Am Sonntag, 28. Juni 2009 schrieb Steve Langasek: > On Sun, Jun 28, 2009 at 01:47:39AM +0200, Timo Weingärtner wrote: > > Package: wnpp > > Severity: wishlist > > X-Debbugs-CC: debian-devel@lists.debian.org > > > >Package name: openssh-known-hosts > > Version: 0.2 > > Upstream Author: Timo Weingärtner > > URL: will go to mentors.debian.net as soon as I get the bug > > number License: GPL2+ > > Description: This package allows you to download public hostkeys from > > multiple sources and merge them together into one file > > for use by OpenSSH. Plugins for some types of sources are included, new > > plugins can easily be written. > > How does this avoid *totally negating* the security value of doing SSH host > key validation? Oh, this is missing in the package description. curl can use https and the curl and rsync plugins can do gpg verification. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: Bug#612752: Bind fails to start if $OPENSSL_CONF is set
Am Freitag, 25. Februar 2011 schrieb Peter Palfrader: > On Thu, 10 Feb 2011, Ben Hutchings wrote: > > Package: bind9 > > Version: 1:9.7.2.dfsg.P3-1.1 > > > > I'm not sure whether this is a bug or my own configuration error. > > > > In interactive shells, I set $OPENSSL_CONF to point to the configuration > > file for my local CA. BIND should not use this, and indeed does not have > > permission to access it. However some part of OpenSSL initialisation > > (used for DNSSEC now?) honours it and fails due to the permission error. > > This is not logged anywhere; I had to use strace to work out where it > > failed. > > We should probably start a campaign in Debian to have all init scripts > sanitize the environment of daemons they start. > > I usually run initscripts using "env -i /etc/init.d/$foo start" to > achieve exactly that, but ideally the init script itself would do that. > > Maybe start-stop-daemon should have an option to delete all but a > specified set of environment variables, maybe even enabled by default. service (8) does that already. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: Introducing vcswatch
Hi, 2014-07-04 23:04:33 Christoph Berg: > To fix that, there's now a service running at qa.debian.org which > grabs the Sources files from unstable and experimental, notes all > Vcs-* URLs, makes checkouts, and compares the debian/changelog file > seen there with the current version in the archive. Nice. So it will only work for workflows where each commit updates d/changelog? Are there plans to check for commits on the branch since the tag corresponding to the version in debian? Perhaps even d/gbp.conf (or similar) could be parsed to figure out the tag naming. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: Standardizing the layout of git packaging repositories
2014-08-18 14:27:15 Thorsten Glaser: > On Sun, 17 Aug 2014, Jonathan Dowland wrote: > > On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote: > > > - encoding (due to git restrictions): > > > ":" -> "%" > > > "~" -> "_" > > I’d rather have something that sorts like Debian versions > in “git tag” output… Including the tilde-sorts-before-empty rule? I'm curious to see a solution to this that doesn't make the tags look ugly. Timo signature.asc Description: This is a digitally signed message part.
Re: Does "recovery mode" imply read-only filesystem ?
Hi, 2014-08-22 14:17:33 Olivier Berger: > I had the impression that the "recovery mode" default grub entry was > meant for booting with read-only, but can't manage to spot > documentation. You can boot with "ro" and "init=/bin/bash" to get a shell without anything trying to remount read/write. Timo signature.asc Description: This is a digitally signed message part.
abstraction library and linkage
Hi,
consider a library libabstr implementing an interface and a library libimplX
that is currently used by libabstr to actually do stuff. The public headers
are called abstr.h and implX.h
libabstr could be designed in basically two different ways:
1: * abstr.h contains just prototypes, perhaps also inline functions that
only call libabstr functions
* libabstr is linked with -limplX
* applications are linked with -labstr
2: * abstr.h contains only inline functions that call libimplX functions
* libabstr is neither built nor linked, libabstr-dev ships a pkg-config
file or similar
* application build process uses pkg-config to determine what to link with
In each case no changes to the source of applications are needed if libabstr
decides to use libimplY instead, in case 1 it may even work without a
rebuild.
Here comes the tricky part:
What shall maintainers of applications using libabstr do if:
* libabstr used to fit way 1
* an inline function in abstr.h now contains:
__asm ("" : : "r" (&libimplX_foo));
so no real calls to libimplX functions are done from the header, but the
application is forced to link with -limplX
* no pkgconfig file or similar is provided
* the change in libabstr was introduced in a debian release
* the breakage from that change is not documented in debian/NEWS
Greetings
Timo
signature.asc
Description: This is a digitally signed message part.
Re: devotee (debian vote engine): predictable RNG allows recovery of secret monikers
Hi, 2012-04-26, 23:23:54 Timo Juhani wrote: > Raphael Geissert writes: > > print hmac_sha1_hex($v, $m); > > Yeah that sounds promising. Now we just need to fix the code that tries > to randomize the order of entries in the tally. Is that randomization really needed? Why not just sort based on the hashes? Greetings Timo signature.asc Description: This is a digitally signed message part.
Bug#722950: ITP: ssh-agent-filter -- filtering proxy for ssh-agent
Package: wnpp Severity: wishlist Owner: "Timo Weingärtner" * Package name: ssh-agent-filter Version : 0.2 Upstream Author : Timo Weingärtner * URL : https://github.com/tiwe-de/ssh-agent-filter * License : GPL3+ Programming Lang: C++, Shell Description : filtering proxy for ssh-agent This package solves the all-or-nothing problem regarding ssh-agent forwarding. It contains: * ssh-agent-filter, the filtering proxy itself * afssh, a wrapper around ssh-agent-filter and ssh Packaging is prepared, an upload to mentors is waiting for the bug number. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130914181618.12163.70523.report...@timo03.72b.tiwe.de
Re: Bug#722950: ITP: ssh-agent-filter -- filtering proxy for ssh-agent
Hi, On Sun, 2013-09-15 11:48:01 Paul Wise wrote: > On Sat, Sep 14, 2013 at 8:16 PM, Timo Weingärtner wrote: > > Packaging is prepared, an upload to mentors is waiting for the bug number. > > FYI, ITP stands for *intent* to package. The ITP comes before the > package to prevent duplication of effort. If you make a package before > filing the ITP there is very little point in filing the ITP at all. I know. I already had that package locally, so the ITP should really be an ITU (intent to upload). Timo signature.asc Description: This is a digitally signed message part.
Bug#662080: ITP: hadori -- Hardlinks identical files
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: hadori Version: 0.2 Upstream Author: Timo Weingärtner URL: https://github.com/tiwe-de/hadori License: GPL3+ Description: Hardlinks identical files This might look like yet another hardlinking tool, but it is the only one which only memorizes one filename per inode. That results in less merory consumption and faster execution compared to its alternatives. Therefore (and because all the other names are already taken) it's called "HArdlinking DOne RIght". . Advantages over other hardlinking tools: * predictability: arguments are scanned in order, each first version is kept * much lower CPU and memory consumption * hashing option: speedup on many equal-sized, mostly identical files The initial comparison was with hardlink, which got OOM killed with a hundred backups of my home directory. Last night I compared it to duff and rdfind which would have happily linked files with different st_mtime and st_mode. I need a sponsor. I'll upload it to mentors.d.n as soon as I get the bug number. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: upstart: please update to latest upstream version
Hallo, 2012-03-14 um 01:30:45 schrieb Paul Wise: > On Wed, Mar 14, 2012 at 7:33 AM, Juliusz Chroboczek wrote: > > (There's a third issue, of course, which is whose environment the daemon > > should be inheriting -- the sanitised environment of init, or the > > environment of the shell of whoever is running "/etc/init.d/foo start" > > or whatever.) > > That is one of the stated advantages of systemd, for sysvinit you are > reliant on the /etc/init.d/foo script to sanitise things in a sane > way. Why do people always forget that there is service(8)? Grüße Timo signature.asc Description: This is a digitally signed message part.
Differing behaviour of shells regarding simple commands with parameter assignments
Hi,
I just stepped over a difference between bash and busybox. To illustrate I
wrote this simple script:
--
#!/bin/sh
bar () { echo -n $foo; }
foo=1
bar
foo=2 bar
bar
--
bash, zsh, posh output 121
busybox sh, dash, (m)ksh output 122
checkbashisms doesn't complain.
Which of the three is wrong? Where shall I file bugs?
When bar is not a function but an external script the output is 121 with all
the shells.
Greetings
Timo
signature.asc
Description: This is a digitally signed message part.
Re: Differing behaviour of shells regarding simple commands with parameter assignments
Hi, 2012-12-26, 02:22:45 Cyril Brulebois wrote: > Timo Weingärtner (26/12/2012): > > bash, zsh, posh output 121 > > > > busybox sh, dash, (m)ksh output 122 > > > > checkbashisms doesn't complain. > > > > Which of the three is wrong? Where shall I file bugs? > > > > When bar is not a function but an external script the output is 121 > > with all the shells. > > you may want to check something like that: > > http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#t > ag_02_09_05 Thanks. If I read that correctly bash, zsh, posh are wrong, but I see that changing that might cause trouble. As this might be a source for subtle errors, especially when external scripts are turned into shell functions or vice versa, would you find it useful to add a warning to checkbashisms? Possible portable workarounds might be (depending on what is expected): * foo=2; bar * (foo=2 bar) * oldfoo=$foo; foo=2; bar; foo=$oldfoo; unset oldfoo with the last one hopefully being rarely needed. Greetings Timo signature.asc Description: This is a digitally signed message part.
Bug#697270: PC 32-bit programs fails to work on amd64
clone 697270 -1 retitle -1 misleading error message when ELF interpreter does not exist reassign -1 bash severity -1 normal merge -1 609882 retitle 697270 i386 multiarch not enabled and ia32-libs not installed by default on amd64 severity 697270 minor tags 697270 +wontfix thanks Hi Alexey, 2013-01-03 um 18:32:28 schrieb Russ Allbery: > Alexey Eromenko writes: > > User error? Huh ? > > > > No ! This is a Debian Bug ! > > Debian clearly says: "File does not exist", while in fact it DOES EXIST. > > This is a 100% proof of Debian bug. I guess it is bash telling you that. > That's the error message that you get when the dynamic loader for a binary > doesn't exist. I think that's been the case for as long as Linux has > existed. That's already reported as bug #609882. For the second part: most people won't need i386 libs on a amd64 system, so this is obviously a wontfix. You can still install ia32-libs if you need them and follow the instructions for enabling multiarch for i386. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: Bug#697270: PC 32-bit programs fails to work on amd64
Hallo Russ Allbery,
2013-01-03 um 19:26:46 schriebst Du:
> Timo Weingärtner writes:
> > 2013-01-03 um 18:32:28 schrieb Russ Allbery:
> >> Alexey Eromenko writes:
> >>> User error? Huh ?
> >>>
> >>> No ! This is a Debian Bug !
> >>> Debian clearly says: "File does not exist", while in fact it DOES
> >>> EXIST. This is a 100% proof of Debian bug.
> >
> > I guess it is bash telling you that.
> >
> >> That's the error message that you get when the dynamic loader for a
> >> binary doesn't exist. I think that's been the case for as long as
> >> Linux has existed.
> >
> > That's already reported as bug #609882.
>
> I think that's asking quite a lot of bash. Wouldn't it have to open the
> binary and parse the ELF headers, extracting the INTERP header, in order
> to verify that? Does it really make sense to encode understanding of ELF
> binary layout formats in bash?
As seen in strace bash already checks for existance of the script and the
#!interpreter. So when execve threw a ENOENT ("The file filename or a script
or ELF interpreter does not exist, or a shared library needed for file or
interpreter cannot be found.") it could at least say something like
"interpreter or libs not found, try ldd for debugging".
Grüße
Timo
signature.asc
Description: This is a digitally signed message part.
Re: unsafe use of gpg
Hallo,
2012-12-15 um 17:12:54 schrieb Peter Samuelson:
> You're right, in gpgv, it appears you _can't_ suppress the default
> keyring, ~/.gnupg/trustedkeys.gpg. So either ensure that this file
> does not exist, or set HOME or GNUPGHOME or --homedir to a location
> where it will not exist.
$ strace gpgv foo.sign 2>&1 | grep ^open.*gpg
open("/home/timo/.gnupg/trustedkeys.gpg", O_RDONLY) = 3
open("/home/timo/.gnupg/trustedkeys.gpg", O_RDONLY) = 5
$ strace gpgv --keyring pubring.gpg foo.sign 2>&1 | grep ^open.*gpg
open("/home/timo/.gnupg/pubring.gpg", O_RDONLY) = 3
open("/home/timo/.gnupg/pubring.gpg", O_RDONLY) = 5
open("/home/timo/.gnupg/pubring.gpg", O_RDONLY) = 6
That's exactly the behaviour described in the manpage:
> By default it uses a keyring named ‘trustedkeys.gpg’ which is assumed to be
> in the home directory as defined by GnuPG or set by an option or an
> environment variable. An option may be used to specify another keyring or
> even multiple keyrings.
Grüße
Timo
signature.asc
Description: This is a digitally signed message part.
Re: alternative debian/rules
Hallo Игорь Пашев, 2013-04-05 um 13:32:24 schriebst Du: > I've just realized that debian/rules might not be a makefile, but can > be a script in any language. > > Is there any package using debian/rules whihc is not a makefile? > Are there any packages that can get advantages by using debian/rules > written in bash/perl/python/etc? See http://bugs.debian.org/636016 ;-) Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Point 1 of Social Contract
Hi, 2014-05-04 14:24:16 Solal: > [GR2004-2] have nothing to do with it. > My proprosition is just warn about proprietary software dangers, but > users would still install non-free software from repositories, get help > from developers, etc. But they are warned. The installer already asks whether to enable non-free repositories. Perhaps the warning could be more verbose differentiating between open-source-but-non- free (GFDL etc.) and closed-source. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: Demande
Hi Nadia, 2014-05-21 11:58:15 nadia ziane: > Je suis ingénieur en informatique , et j'aimerais bien rejoindre l'équipe > de développement debian mais j'aimerais savoir quels sont les conditions > pour y faire? Please read https://www.debian.org/devel/join/. > quels sont les connaissances techniques indispensables? You should be able to read and write in English. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: How to provide support for -i386 utilities within -amd64 packages?
Hi Carl, 2014-05-21 15:41:44 Carl Worth: > I'm interested in packaging (or helping to package) several programs and > libraries related to OpenGL, (such as apitrace, vogl, fips, and waffle). > > For each of these packages I have a question about best practices > related to supporting 32-bit libraries and binaries within a 64-bit > system. > > Imagine a package (waffle-utils, say) that installs a program > (/usr/bin/wflinfo, say) that reports some information about a library > (libGL.so, say) against which it is linked. > > So on either an -i386 or an -amd64 system, a user could install the > native package, run the program, and query the native library. > > But now imagine a user with an -amd64 system that has an alternate -i386 > library provided by a multilibs package (such as libgl1-mesa-glx:i386). > It would be useful for such a user to have both the native 64-bit > program and a 32-bit program available at the same time, (to be able to > query either library). If it's just version information the results across all architectures will be the same because you can only install one version of a Multi-Arch: same package. If you need more information consider doing it like libc: add a main() to the lib to display that information. Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: how to divert /etc/profile?
Hi Harald, Am Montag, 2011-07-04 schrieb Harald Dunkel: > I would like to install a private package diverting > /etc/profile (to support /etc/profile.d). Problem: > There is no owner for this file. > > What would you suggest? > > > Any helpful comment would be highly appreciated. See /usr/share/doc/base-files/README. The version in squeeze already includes support for profile.d. Greetings Timo signature.asc Description: This is a digitally signed message part.
multiarch coinstallability of libc6 / conflicting loader paths
Hi, last week I tried exploiting multiarch to set up a machine to build and run binaries for multiple architectures. So I enabled architectures in dpkg, updated the package lists and tried installing libc6 packages for each architecture, but dpkg refused to unpack libc6:mipsel after libc6:powerpc had been installed, because both architectures use the same path for their dynamic loader: /lib/ld.so.1 A look into the archive revealed two groups of conflicting loader paths: /lib/ld.so.1: hppa hurd-i386 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe s390 /lib/ld-linux.so.2: alpha i386 sh4 sparc Other architectures have loader paths containing the architecture name (amd64 arm64 armhf kfreebsd-amd64 x32) or ones that are merely unique: /lib/ld- linux.so.3 (armel), /lib/ld64.so.1 (s390x), /lib64/ld64.so.1 (ppc64), /lib64/ld64.so.2 (ppc64el), /lib64/ld-linux.so.2 (sparc64). The problem is that loader paths are hard to change, at least for binaries that need to be run at boot time. Later we can use binfmt-support to call the loader with its multiarch'ed path or change qemu-user in that way. A short-term fix for the dpkg errors could be to express the conflicting loader paths with Conflicts: between the relevant libc6 packages. My proposal for a long-term solution is: * qemu-user redirects loader names to multiarch'ed paths * libc6 adds binfmt entries for the native architectures * libc6 removes the loader symlinks from the package tarball and instead creates it in maintainer scripts for the native architecture(s) Is that a workable plan or did I miss something? Greetings Timo signature.asc Description: This is a digitally signed message part.
Re: ask github to encourage signed git tags
Hi,
2015-08-21 09:51:45 Thomas Koch:
> we want upstream to sign releases. Nowadays a lot of software is on github
> and a release is just a git tag. - An unsigned git tag ... :-(
>
> Github has a site that shows tags[1] but it does not give any indication
> whether the tag is signed or not.
> [1] e.g. https://github.com/Flameeyes/unpaper/tags
>
> Github should add visual feedback on this tags page: grey for unsigned,
> yellow for signed and green for signed and connected to the web-of-trust.
> Next to a grey or yellow tag there should be links to help texts.
Connected to the WOT means the strong set?
While I think signed tags are enough, many things rely on signed tarballs.
github should thus also allow uploading signatures for the tarball generated
from the (signed) tags and provide instructions for how to generate the
tarballs yourself.
I can generate github-identical tarballs with:
$ git archive --prefix="${PROJECT}-${TAG}/" -o
"${HOME}/build-area/${PROJECT}_${TAG}.orig.tar.gz" "${TAG}"
> Yes, github is proprietary. Still it would be in the best interest of
> everybody if software was signed. Even github would not want to host
> malicious code.
Signed software does not imply non-malicious code.
Regards
Timo
signature.asc
Description: This is a digitally signed message part.
Re: Recreating history of a package
Hallo, 16.02.19 21:24 Ben Hutchings: > On Sat, 2019-02-16 at 14:17 +0100, Guillem Jover wrote: > > On Sat, 2019-02-16 at 12:22:04 +, peter green wrote: > > > 2. Snapshot.debian.org is only offered over plain insecure http. For > > >recent versions the packages can be verified against the > > >Packages/Sources files which can in turn be verified with gpg but > > >older versions are more problematic to verify as the relevant > > >packages/sources files are only signed with 1024 bit keys or not > > >signed at all. This is made worse by the fact that > > >snapshot.debian.org has an API to obtain the first snapshot a > > >package is available in but not any API to find the last snapshot > > >it was available in. > > > > http://snapshot.debian.org/ is now offered over https too. Its front-page > > even documents its usage as such. :) > > And it has HSTS, which is nice, but it is missing the redirection > that's needed to make that work completely. I guess global HTTP redirects might break older apt setups without apt- transport-https installed. For browsers it should be enough to add the redirects for the HTML pages. Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Check if config files were changed during package installation
Hallo Олег Михайлов, 16.08.23 16:38 Олег Михайлов: > I want to create a package, which acts in the following manner: > - If configs were not changed by dpkg during installation, restart service > immediately after installation; > - If configs were changed by dpkg during installation, do not restart > service (either stop, or do not start). Why would you want to do that? It's definitely what I would expect from a package. > As far as I remember, if default configs in a package differ from previous > package configs, dialogue will be shown. By default the dialogue is shown if both the new package version and the file on disk differ from each other and the old package version. But it can be overridden with --force-conf* > Can I somehow automatically check > its result during package installation process and make it a condition in > postinst (or even solve the problem via 'rules' somehow)? So you want to check if the conffile on disk matches (or has the same hash as) the one in the package? /var/lib/dpkg/status contains md5sums of conffiles, but I don't remember when in the install process they're updated. Or you could produce your own hash sum, ship it in the package and compare in postinst. Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Debconf - adding "treeselect" type(s)?
Hallo Steve McIntyre, 29.11.20 20:21 Steve McIntyre: > On and off, I've been hacking on tasksel for quite a while to improve > the UI there and add better support for things like Blends. I've made > some progress in my hacking, but I think I've hit a brick wall and I > need to change tack. :-/ > > What I've ended up doing so far is hacking tasksel to give a poor > *approximation* of a tree-style layout: classifying some existing > tasks under headers and building a tree, then displaying each of the > nodes of the tree one level at a time via the existing debconf > setup. It just about works, but it's ugly as all hell and I'm not > happy with where I've got to. I've sunk a lot of development time into > this, but I don't think it's ready to fly this way. :-( > > What I *actually* need here is proper support in debconf for > tree-style selection. I'm thinking of adding that, adding new types > "treeselect" as a tree-equivalent of "select" and "multitreeselect" as > an extension of "multitselect". The first one may not even be needed, > but would be a trivial simplification of the second, so *meh*. What are the proposed semantics of this multitreeselect? If we imagine something like: [ ] a [ ] a/b [ ] a/c [ ] b [ ] b/a Would checking "a" automatically also check "a/*"? Is it only about UI, meaning "a/*" would be collapsed under "a"? Shall it be possible to check "a", but uncheck "a/b"? Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Debconf - adding "treeselect" type(s)?
Hallo Steve McIntyre, 30.11.20 16:36 Steve McIntyre: > I'll admit that I'm thinking of this *mostly* in terms of the needs of > tasksel so far, but I'd expect switching to a new template type is > likely to need a rethink to make best use of them anyway. In my mind there is also locales where we should have three levels: de de_AT de_DE [ ] de_DE [ ] de_DE@euro [ ] de_DE.UTF-8 en en_DK en_GB en_US Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Facilitating external repositories
Hallo Wouter Verhelst, 03.11.19 18:35 Wouter Verhelst: > The software from the package downloads the metadata index and validates > the GPG signature; and if everything checks out, adds configuration to > /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the > repository. Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is in there its owner can impersonate the official debian repos for default setups.¹ Please use some other path (such as /var/lib/extrepo/keyrings/) for the keyrings and connect it with "Signed-By:" [1]. I just changed my /etc/apt/sources.list.d/debian.sources to have: Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg Grüße Timo ¹ there are still other attack vectors as soon as you install a package from such a repo [1] sources.list(5) signature.asc Description: This is a digitally signed message part.
apt: deprecate /etc/apt/trusted*
Package: apt Version: 1.8.4 Severity: normal Hallo Ansgar, 04.11.19 09:44 Ansgar: > Paul Wise writes: > > On Mon, Nov 4, 2019 at 4:52 AM Guillem Jover wrote: > >> The official archive-keyring packages that use these, I think it's mostly > >> for backwards compatibility reasons. > > > > I wonder if it is feasible to and how the debian-archive-keyring could > > migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ + > > signed-by. Right now it ships keyrings in both places. > > I would recommend against doing this as long as sources.list is a > configuration file: it would need regular updates to change to the new > signing key. That doesn't work out of the box. Maybe apt could deprecate /etc/apt/trusted* and apt-key(8) in bullseye and abandon them in bullseye+1. The whole concept of having one keyring that authenticated all sources is wrong. I had my share in making /etc/apt/ trusted.d possible, but now that we have "Signed-By:" it is the inferior solution and thus not needed anymore. d-i should start to create sources.list with "Signed-By:" right now, #944102 [1]. apt or debian-archive-keyring could provide a migration script for sources.list entries without "Signed-By:" which could — at least for origin=Debian — add the correct "Signed-By:" option. Grüße Timo [1] https://bugs.debian.org/944102 signature.asc Description: This is a digitally signed message part.
Re: Master-Slave terminology Re: [Piuparts-devel] piuparts.d.o stalled?
Hallo Ulrike, 12.02.20 17:46 Ulrike Uhlig: > On 12.02.20 17:01, Nicolas Dandrimont wrote: > > In any case, since DSA had to restart everything at UBC, the piuparts > > slave got restarted as well and it's churning through the backlog. > > Unfortunately it looks like restarting the slave just eats its logs. > > I'd like to attract your attention to this very fine document: > > https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1 > > Quoting from there: "Master-slave is an oppressive metaphor that will > and should never become fully detached from history." > > As an alternative: > "Several options are suggested here and should be chosen based on the > pairing that is most clear in context: > > Primary-secondary > Leader-follower > Active-standby > Primary-replica > Writer-reader > Coordinator-worker > Parent-helper > " I don't think giving slaves new labels helps them in any way; they will still be slaves. Or do you intend to actually liberate them? If yes: how? which liberties are they supposed to gain? If no: then you're actually helping the slave owners hiding their wrongdoings. Grüße Timo signature.asc Description: This is a digitally signed message part.
behaviour of "systemctl kexec" not matching man page, sabotaging kexec reboots with kexec-tools
Hallo, some Debian releases ago I used to use kexec-tools to do kexec reboots with sysvinit. With the advent of systemd I used "systemctl kexec" with kexec-tools installed and it worked as intended. Some time ago it started failing and I didn't care because I didn't have bare metal servers running Debian at that time. In my current dayjob I'm again responsible for a bunch of servers so I resumed to care and researched why "systemctl kexec" fails. According to systemctl's man page "systemctl kexec" is just an alias for "systemctl start kexec.target --job-mode=replace-irreversibly --no-block". If I invoke the latter with kexec-tools installed it actually works. If I use "systemctl kexec" the error messages are one of: 8<8<8< /sbin/kexec is not available: No such file or directory 8<8<8< on a system with no kexec-tools installed which is actually helpful 8<8<8< Cannot find the ESP partition mount point. 8<8<8< on a buster system with BIOS-boot and kexec-tools installed which is misleading, because I do not need EFI for kexec to work 8<8<8< No entry suitable as default, refusing to guess. 8<8<8< on a buster system with EFI-boot and kexec-tools installed which is highly irritating and not helpful 8<8<8< No kexec kernel loaded and autodetection failed. Automatic loading works only on systems booted with EFI. 8<8<8< on a bullseye system with BIOS-boot and kexec-tools installed which is factually wrong because kexec-tools will do the loading (later) just fine I understand that systemd authors try to tell the user when a fast (kexec) reboot is not to be expected, but the heuristic is wrong on all systems I got my fingers on. Even if kexec reboots worked on systems with EFI-boot it would not be an option to reinstall all the servers. IMO there are some options to proceed: 1) improve the heuristic in systemctl so that it succeeds if kexec-tools is installed, maybe with some option in system.conf. 2) work around the systemd bug in kexec-tools by loading the kernel at boot and kernel install times¹, wasting about 40 MiB of RAM. 3) provide a wrapper script (say "kexecreboot") in kexec-tools that runs the long version above and also loads a kernel in the case of sysvinit with kexec-tools/load_kexec=false. 4) provide a wrapper script and dpkg-divert systemctl. Grüße Timo ¹ that would miss kernel cmdline changes with only update-grub, but I couldn't find useful hooks for that -- ITscope GmbH Ludwig-Erhard-Allee 20 D-76131 Karlsruhe Tel: +49 721 627376-0 Fax: +49 721 66499175 https://www.itscope.com Handelsregister: AG Mannheim, HRB 232782 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Alexander Münkel, Benjamin Mund, Stefan Reger signature.asc Description: This is a digitally signed message part.
Re: Bug#963191: RFH: aufs
Hallo, 20.06.20 13:26 Bastian Blank: > 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? 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. Grüße Timo -- ITscope GmbH Ludwig-Erhard-Allee 20 D-76131 Karlsruhe Tel: +49 721 627376-0 Fax: +49 721 66499175 https://www.itscope.com Handelsregister: AG Mannheim, HRB 232782 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Alexander Münkel, Benjamin Mund, Stefan Reger signature.asc Description: This is a digitally signed message part.
Bug#838989: Debian 8.0 ipv6 bug
27.09.16 19:14:31 CEST Asim Shaikh: > Package: general > Severity: important > > Ipv6 Stops working exactly after 30 mins on debian 8.0 and 7.8. > The ipv6 configuration is written in the network file and not added a alias. What configuration is written in which file(s) (full path, please)? What is the output of: ip -6 a ; ip -6 r after configuration/boot and after 30 minutes? Regards Timo signature.asc Description: This is a digitally signed message part.
Re: pro-tip: preinstall debhelper in your sbuild
2017-03-24 16:18:10 CET Adam Borowski: > On Fri, Mar 24, 2017 at 07:30:55PM +0500, Andrey Rahmatullin wrote: > > On Fri, Mar 24, 2017 at 03:25:59PM +0100, Adam Borowski wrote: > > > autoremove will still usually catch this. > > > > I'm not sure about this. Looks like it keeps Recommends or something. Or > > it's a bug. > > I'd say that apt autoremove keeping Recommends even when called with > --no-install-recommends is a reasonable behaviour. Same for > Priority:important or Important:yes packages. The sbuild case is quite > special. > > The functionality to keep a system squeaky clean would probably be better in > debfoster, but alas, it's effectively unmaintained. These apt settings keep my systems clean and I guess they would also help build chroots: Apt::AutoRemove::RecommendsImportant "false"; Apt::AutoRemove::SuggestsImportant "false"; Apt::Install-Recommends "false"; Apt::Install-Suggests "false"; Sometimes I even do: # aptitude purge '~i ~M !~E !~R~i !~Rpredepends:~i' to remove old kernels, gcc-*-base, etc. signature.asc Description: This is a digitally signed message part.
Re: The state of cross building
Hi, 2016-01-30 20:08:09 Helmut Grohne: > Let me give a status update on how well cross building works in > unstable. > Processing the logs > --- > > I've hacked up a script that guesses failure reasons by scanning the > logs with some regular expressions. Common issues are: > > * (>800) Using the build architecture compiler or linker. This is claimed for one of my packages (libpam-pwdfile). The build log has an interesting line: > dpkg-architecture: warning: specified GNU system type powerpc64le-linux-gnu > does not match CC system type x86_64-linux-gnu, try setting a correct CC > environment variable And the build fails because the packages's Makefile uses $(CC) and it is not set correctly. I don't think it should be each package's responsibility to set variables like CC, CXX, AR, etc. Instead they should be set by dpkg-buildpackage or perhaps dh_auto_*. Timo signature.asc Description: This is a digitally signed message part.
Re: The state of cross building
Hi Helmut, 2016-01-31 15:58:17 Helmut Grohne: > Unfortunately, for Makefile based build systems we cannot simply pass CC > to the build. Exporting it as an environment variable, will not help > much as make defines CC as a builtin variable, which overrides the > environment. In the vast majority of cases, exporting is not enough. In > particular, libpam-pwdfile is an example where this is happening and > where having dpkg-buildpackage export CC does not fix the build. make just defaults CC to cc so setting CC in the surrounding environment works as intended, even without a Makefile. Just try: "CC=clang make foo" with a foo.c in the directory. There are however packages that explicitly set CC (to gcc) and other variables in the Makefile which is very annoying and IMO a bug. Timo signature.asc Description: This is a digitally signed message part.
