Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-08 19:12]: Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
2021, സെപ്റ്റംബർ 9 4:42:18 AM IST, Michael Stone ൽ എഴുതി >On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: >>Enabling https by default quite simply breaks the simple recipe of >>installing auto-apt-proxy. Would you agree with auto-apt-proxy's >>postinst automatically editing your sources.list to drop the s out of >>https? The answer repeatedly given in this thread to do so manually is >>very unsatisfying. > >Why not simply automate setting it at install time using preseed? I'm >honestly not sure who the target audience for auto-apt-proxy >is--apparently someone who has an infrastructure including a proxy, >possibly the ability to set dns records, etc., but can't change defaults >at install time or via some sort of runtime configuration management? > Why can't auto-apt-proxy ask this as a debconf question? I also like auto-apt-proxy but I agree with this, someone needing auto-apt-proxy should be able to change the default as well. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Wine MinGW system libraries
On 9/9/21 12:45 AM, Paul Wise wrote: On Thu, 2021-09-09 at 00:39 -0500, Zebediah Figura wrote: Right, but we don't have any guarantee that library A will load library B in its constructor routines. In fact, if it's loading library B dynamically, it's probably not doing that. Can the loader tell which library asked it to load a library? Then the namespace could be inherited from the parent library. Unfortunately, no. We have no way of knowing the caller.
Re: Wine MinGW system libraries
On Thu, 2021-09-09 at 00:39 -0500, Zebediah Figura wrote: > Right, but we don't have any guarantee that library A will load library > B in its constructor routines. In fact, if it's loading library B > dynamically, it's probably not doing that. Can the loader tell which library asked it to load a library? Then the namespace could be inherited from the parent library. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Wine MinGW system libraries
On 9/9/21 12:15 AM, Paul Wise wrote: On Wed, 2021-09-08 at 23:47 -0500, Zebediah Figura wrote: Unfortunately, while thinking about the answer to this question, I realized another snag, which I think really does make using identically-named dynamic libraries impossible: if system library A loads system library B dynamically, i.e. does the equivalent of a dlopen(), we have no way of knowing which namespace to apply to it. [AFAICT dlmopen() has this problem too, and just isn't meant for that use case.] Even rewriting the import table doesn't help here. While loading library A into a namespace Foo, the loader could set a process global variable containing the current namespace to load into, and then have the dlopen equivalent use namespace Foo in preference to the default namespace for the process. Then when library B is loaded it will go into namespace Foo. Once loading library B and A has completed the loader could revert to using the default namespace. Right, but we don't have any guarantee that library A will load library B in its constructor routines. In fact, if it's loading library B dynamically, it's probably not doing that.
Re: Wine MinGW system libraries
On Wed, 2021-09-08 at 23:47 -0500, Zebediah Figura wrote: > Unfortunately, while thinking about the answer to this question, I > realized another snag, which I think really does make using > identically-named dynamic libraries impossible: if system library A > loads system library B dynamically, i.e. does the equivalent of a > dlopen(), we have no way of knowing which namespace to apply to it. > [AFAICT dlmopen() has this problem too, and just isn't meant for that > use case.] Even rewriting the import table doesn't help here. While loading library A into a namespace Foo, the loader could set a process global variable containing the current namespace to load into, and then have the dlopen equivalent use namespace Foo in preference to the default namespace for the process. Then when library B is loaded it will go into namespace Foo. Once loading library B and A has completed the loader could revert to using the default namespace. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Require packages to build without any configured DNS
On Wed, Sep 8, 2021 at 9:51 PM Pirate Praveen wrote: > I don't think the default autopkgtest environment should be as > restrictive as the build environment. So adding this to default > autopkgtest enviroment is not the same as adding it to default build > environment. It is already the case that the autopkgtest "needs-internet" restriction is not enabled by default. Personally I think that is the right choice, to give people the option of not running such tests on offline machines or where arbitrary outgoing Internet connections are not allowed. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Wine MinGW system libraries
On 9/8/21 8:12 PM, Paul Wise wrote: On 9/8/21 3:13 AM, Simon McVittie wrote: As far as I understand it, the PE loader used for Wine is part of Wine, so it has total control over the libraries that it loads and how it loads them. This means that if Wine developers (the experts on this codebase) have decided a libcapsule-like approach isn't feasible or isn't desirable, they are probably right. Could the PE loader add support for some sort of namespaces and then be told to load Wine dependencies within a Wine namespace? Does the Microsoft Windows loader support anything like this? Recompiling every PE library with special flags or renaming every PE library with a Wine prefix seems a bit tedious if just the PE loader and anything that requests Wine deps can use a namespace/capsule/etc. The closest thing that Windows has is SxS, which is meant to solve I think some of the same problems (well, it's mainly meant to solve the versioning problem that Microsoft dug themselves into). The problem is that I believe it requires the namespace to be effectively hard-coded into the library in question, in the form of a manifest resource. Unfortunately, while thinking about the answer to this question, I realized another snag, which I think really does make using identically-named dynamic libraries impossible: if system library A loads system library B dynamically, i.e. does the equivalent of a dlopen(), we have no way of knowing which namespace to apply to it. [AFAICT dlmopen() has this problem too, and just isn't meant for that use case.] Even rewriting the import table doesn't help here.
Re: Require packages to build without any configured DNS
On Wed, Sep 8, 2021 at 8:23 PM Thomas Goirand wrote: > Later on, the class calls the method read_resolv_conf that has: It also fails if the file exists but has no nameservers: if len(self.nameservers) == 0: raise NoResolverConfiguration > So, any test case that does that fails simply because the *FILE* > /etc/resolv.conf isn't there on the filesystem (and not because there's > no working DNS server, which would be just fine). That seems like a bug in the test cases, they shouldn't be testing the build time environment like that, since it could differ from the runtime environment. There are nss_wrapper/resolv_wrapper for mocking away the build-time DNS resolving infrastructure. https://cwrap.org/nss_wrapper.html https://cwrap.org/resolv_wrapper.html > One could argue that the test cases should aways instantiate the > Resolver object with a non-default (test only) filename argument. Agreed. > I agree with that: please propose such a patch upstream. But does it > deserve anyone time? I don't think so. We're achieving absolutely > nothing doing this: this doesn't improve Debian... It improves support for offline systems, which often don't have a working /etc/resolv.conf -- bye, pabs https://wiki.debian.org/PaulWise
Re: Wine MinGW system libraries
On 9/8/21 3:13 AM, Simon McVittie wrote: > As far as I understand it, the PE loader used for Wine is part of Wine, > so it has total control over the libraries that it loads and how it loads > them. This means that if Wine developers (the experts on this codebase) > have decided a libcapsule-like approach isn't feasible or isn't desirable, > they are probably right. Could the PE loader add support for some sort of namespaces and then be told to load Wine dependencies within a Wine namespace? Does the Microsoft Windows loader support anything like this? Recompiling every PE library with special flags or renaming every PE library with a Wine prefix seems a bit tedious if just the PE loader and anything that requests Wine deps can use a namespace/capsule/etc. On Wed, 2021-09-08 at 10:42 -0500, Zebediah Figura wrote: > The basic reason is that Wine is essentially trying to split itself into > "PE" and "Unix" parts. The idea is that all of the "user" code is built > in PE format, and only calls into unix code by making a sort of fake > syscall. The "kernel" code is built in ELF format. > > There are a few basic reasons for doing this: Definitely seems like the right thing to do for Wine. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
All, I am against automatically setting HTTPS. Their should be an option in the installer to set or unset HTTPS while configuring the mirror! I like a lot of folks am on a metered internet connection with a UTM proxy firewall. I have multiple computers that need patched and only having to download the package once is a great convenience to both data usage and download time as my internet is not fast 4G LTE usually only operating at 3G speed. Tim
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 03:56:14PM +0200, Ansgar wrote: On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote: On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > So what do you suggest then? Tech-ctte as with merged-/usr? Or a > GR? Or > something else? I propose that the proponents pay the cost. In this case, it is a bit unclear what that means precisely (which likely is the reason they haven't done it already). At the very least though, apt install auto-apt-proxy should continue to work on a default installation in a sensible way. I can file a bug for auto-apt-proxy to include an apt.conf snippet saying Acquire::https::Verify-Peer false; That clearly makes it work again I think the issue isn't certificate validation, it's that https proxy requests are made via CONNECT rather than GET. You could theoretically rewrite the proxy mechanism to MITM the CONNECT, but that wouldn't be a drop-in replacement. I suppose you could instead add an apt option to pass the https request to the proxy via GET instead of using CONNECT, but I think that also won't necessarily work on an existing proxy. If we're imagining apt options, something like Acquire::https::Force-Proxy-HTTP true; would probably be more useful for this specific case (not that I think it's a great idea--too much potential for surprise).
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: Enabling https by default quite simply breaks the simple recipe of installing auto-apt-proxy. Would you agree with auto-apt-proxy's postinst automatically editing your sources.list to drop the s out of https? The answer repeatedly given in this thread to do so manually is very unsatisfying. Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management?
Re: Ideas for a dh-privacy-helper
Quoting Jonas Smedegaard (2021-09-04 20:02:57) > Quoting Bastien ROUCARIES (2021-09-04 19:52:50) > > Le ven. 3 sept. 2021 à 01:03, Jonas Smedegaard a écrit : > > > > > > Quoting Bastien Roucariès (2021-09-02 23:45:30) > > > > Perl is an option I implemented the privacy breach test in perl. > > > > The problem is I prefer to drop a debian/package.privacy.xslt > > > > file in the package instead of asking maintainer to code the > > > > removal of privacy problems... > > > > > > > > Generic one could be coded in perl, but for the end side I need > > > > something like xslt2 > > > > > > If you are asking how to sloppily parse HTML5 files from upstream > > > source and XSLT2 files provided by package maintainers, then with > > > perl you could use HTML::HTML5::Parser for the first and > > > XML::Saxon::XSLT2 for the second. > > > > Unfortunatly HTML::HTML5::Parser is RC buggy since 4 years due to a > > bug for handling UTF-8 (#750946) > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750946 > > Ouch! > > I keep forgetting which packages are affected by that annoying bug :-/ > > > > Your suggestion will work fine but we need to get some solution for > > this utf-8 problem... > > I have recently grown somewhat more familiar with UTF-8 and perl (in > my work towards fixing bug#867305 in licensecheck), and will try take > a fresh look at bug#750946... HTML::HTML5::Parser should now be in better shape. Please try version 0.992 now in unstable, if still relevant for your work. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Require packages to build without any configured DNS
On ബു, സെപ്റ്റം 8 2021 at 06:10:56 വൈകു +0300 +0300, Adrian Bunk wrote: On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote: On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand wrote: > Therefore, I am in the opinion that we should let the package run its > test as much as possible, especially considering that it's not doing > actual network outbound connections. Can't we run these tests as autopkgtests? That would only move the problem elsewhere, since this creates a similar question whether such tests should need a "needs-internet" restriction for autopkgtest which might result in them being skipped in most cases. I don't think the default autopkgtest environment should be as restrictive as the build environment. So adding this to default autopkgtest enviroment is not the same as adding it to default build environment.
Re: Require packages to build without any configured DNS
On 9/8/21 5:44 PM, Helmut Grohne wrote: > As such, I err on dnspython being in need of a fix. Dnspython isn't broken in any ways, it doesn't do any network access. The only thing you're going to achieve is: - more work for the maintainers (who will need to disable or patch the tests). - probably less tests (because the maintainer will probably choose to simply disable the tests), which means less quality. Again: what are you trying to achieve? On 9/8/21 6:01 PM, Josh Triplett wrote: > Now, that said, if the build process actually wants a DNS server to > run tests against, it should provide or depend on such a DNS server, > and configure it for such tests. Just to be 100% sure we're on the same page: that's *not* what dnspython is doing. It's a client library that's testing parsing of the /etc/resolv.conf format, and it just expects it to be there for parsing. The code has: class Resolver: def __init__(self, filename='/etc/resolv.conf', configure=True): Later on, the class calls the method read_resolv_conf that has: try: f = stack.enter_context(open(f)) except OSError: # /etc/resolv.conf doesn't exist, can't be read, etc. raise NoResolverConfiguration The test cases are of course instantiating the Resolver object to test it, and calls it with the default configuration (ie: /etc/resolv.conf as default), with something like this: r = dns.resolver.Resolver(configure=False) So, any test case that does that fails simply because the *FILE* /etc/resolv.conf isn't there on the filesystem (and not because there's no working DNS server, which would be just fine). One could argue that the test cases should aways instantiate the Resolver object with a non-default (test only) filename argument. Well, I agree with that: please propose such a patch upstream. But does it deserve anyone time? I don't think so. We're achieving absolutely nothing doing this: this doesn't improve Debian... Cheers, Thomas Goirand (zigo)
Bug#993963: ITP: centreon-plugins -- Collection of nagios plugins to monitor OS, services and network devices
Package: wnpp Severity: wishlist Owner: Baptiste Beauplat X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-nagios-de...@lists.alioth.debian.org * Package name: centreon-plugins Version : 0.0~20210520-1 Upstream Author : Centreon (https://www.centreon.com) * URL : https://github.com/centreon/centreon-plugins * License : Apache-2.0 Programming Lang: Perl Description : Collection of Nagios plugins to monitor OS, services and network devices Free and open source project to monitor systems. The project can be used with Centreon and all monitoring software compatible with Nagios plugins. The following can be monitored: * application: Apache, Asterisk, Elasticsearch, Github, Jenkins, Kafka, Nginx, Pfsense, Redis, Tomcat, Varnish... * cloud: AWS, Azure, Docker, Office365, Nutanix, Prometheus... * database: Firebird, Informix, MS SQL, MySQL, Oracle, Postgres, Cassandra * hardware: printers (rfc3805), UPS (Powerware, Mge, Standard), Sun Hardware, Cisco UCS, SensorIP, HP Proliant, HP Bladechassis, Dell Openmanage, Dell CMC, Raritan... * network: Aruba, Brocade, Bluecoat, Brocade, Checkpoint, Cisco AP/IronPort/ASA/Standard, Extreme, Fortigate, H3C, Hirschmann, HP Procurve, F5 BIG-IP, Juniper, PaloAlto, Redback, Riverbed, Ruggedcom, Stonesoft... * os: Linux (SNMP, NRPE), Freebsd (SNMP), AIX (SNMP), Solaris (SNMP)... * storage: EMC Clariion, Netapp, Nimble, HP MSA p2000, Dell EqualLogic, Qnap, Panzura, Synology... I intend to maintain this package as part of the Nagios team. -- Baptiste Beauplat - lyknode signature.asc Description: PGP signature
Re: Require packages to build without any configured DNS
On Wed, Sep 08, 2021 at 05:44:34PM +0200, Helmut Grohne wrote: > On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote: > > Do anybody on the list have any opinion on where is the bug, on > > dnspython, or on the build environment? > > I concur that the absence of /etc/resolv.conf is a sensible > configuration. Indeed, it is my method-of-choice for implementing > poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It > doesn't actually prevent network access, but makes accidental network > access very unlikely. This does not work when software has a built-in fallback IP when no nameserver is configured in /etc/resolv.conf dnspython removing such a built-in fallback IP address and returning an error instead is what caused the breakage in reproducible builds. >... > As such, I err on dnspython being in need of a fix. What kind of fix? Re-adding a default of 127.0.0.1 (or even 8.8.8.8) when no nameserver is found in /etc/resolv.conf ? dnspython is initialized several packages down in the callstack for the failing packages by a concurrent networking library, and I am not aware of any package in this stack doing something unreasonable. > Helmut cu Adrian
Problem building a Debian package in AFS
I have two Debian servers: one is buster and one is bullseye. They both run the openafs-client service. When I run "gbp buildpackage mypackage" it completes successfully on both servers as long as the directory where I run "gbp" is _not_ in AFS. If I run "gbp" in an AFS directory it completes successfully on the buster server but fails almost immediately if run on the bullseye server. The failed build output on the bullseye server looks like this: - test2-bullseye:~/development/git/vemail> gbp buildpackage dh clean dh_clean gbp:info: Exporting 'HEAD' to '/afs/example.com/users/rlinxster/development/git/build-area/email-virtual-domain-tmp' gbp:info: Moving '/afs/example.com/users/rlinxster/development/git/build-area/email-virtual-domain-tmp' to '/afs/example.com/users/rlinxster/development/git/build-area/email-virtual-domain-11' gbp:info: Performing the build Building with cowbuilder for distribution sid I: using cowbuilder as pbuilder dh clean dh_clean dpkg-source: info: using source format '3.0 (native)' dpkg-source: info: building email-virtual-domain in email-virtual-domain_11.tar.xz dpkg-source: info: building email-virtual-domain in email-virtual-domain_11.dsc I: Generated dsc will be overwritten by build result; not generating changes file E: File not found: ../email-virtual-domain_11.dsc gbp:error: 'git-pbuilder' failed: it exited with 1 - Here is my .gbp.conf (same on both servers): - [DEFAULT] builder = git-pbuilder cleaner = fakeroot debian/rules clean pristine-tar = True [buildpackage] export-dir = ../build-area/ tarball-dir = .. [import-orig] dch = False
Re: Require packages to build without any configured DNS
Mattia Rizzolo wrote: > during the year, a src:dnspython change made it so that any software > importing that library now requires a valid /etc/resolv.conf with at > least one nameserver configured. > > This also made it so that something between 50-100 packages now fail to > build if the build system doesn't have any working /etc/resolv.conf. I > venture to say that this is a very reasonable configuration to have in a > build system that tries to be network-disabled. > > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? I think dnspython's previous approach was correct: just like glibc, musl, and other libraries, if /etc/resolv.conf is missing they should treat that as though it specified a nameserver on localhost. The change to make that a configuration error, instead, breaks real configurations that intentionally don't have /etc/resolv.conf. Among other things, having a DNS server on localhost (or forwarding the DNS port on localhost to your real DNS server) means that a chroot without /etc/resolv.conf still has functional DNS. Now, that said, if the build process actually wants a DNS server to run tests against, it should provide or depend on such a DNS server, and configure it for such tests. But a build process that's just *importing the dnspython library* should not need to have either /etc/resolv.conf *or* a functional DNS server. - Josh Triplett
Re: Require packages to build without any configured DNS
On Mon, Sep 06, 2021 at 04:39:39PM +0200, Mattia Rizzolo wrote: > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? I concur that the absence of /etc/resolv.conf is a sensible configuration. Indeed, it is my method-of-choice for implementing poor-man's network-less builds with sbuild: Delete /etc/resolv.conf. It doesn't actually prevent network access, but makes accidental network access very unlikely. I'm unsure whether /etc/resolv.conf is supposed to be essential. None of the packages in that set ensure its creation. Rather debootstrap and mmdebstrap have extra code to copy the host's /etc/resolv.conf into the chroot. Therefore any created chroot will contain one. However that seems more like an artifact of the bootstrap implementation rather than an intentional guarantee to me. As such, I err on dnspython being in need of a fix. Helmut
Re: Wine MinGW system libraries
On 9/8/21 3:13 AM, Simon McVittie wrote: On Wed, 08 Sep 2021 at 07:31:59 +, Bastien ROUCARIES wrote: Simon, do you think you could implement a version of libcapasule for PE object ? Given that libcapsule is very glibc- and ELF-specific, doesn't work properly without new glibc feature work that isn't in Debian yet (I've lost track of whether/when it got merged upstream, it might be in 2.34) and wasn't written by me, the answer is likely to be no. As far as I understand it, the PE loader used for Wine is part of Wine, so it has total control over the libraries that it loads and how it loads them. This means that if Wine developers (the experts on this codebase) have decided a libcapsule-like approach isn't feasible or isn't desirable, they are probably right. More generally, if Wine developers wanted Wine's dependency libraries to be in one version of reality, and Windows DLLs to be in a different version of reality, then there's a straightforward way to do that: use ELF .so dependency libraries, like older versions of Wine did, and don't give them a representation in the PE layer. Presumably they have put in the work to move from ELF to PE dependency libraries because it has some compelling advantage, rather than creating work for themselves for no reason! Yeah, basically :-) The basic reason is that Wine is essentially trying to split itself into "PE" and "Unix" parts. The idea is that all of the "user" code is built in PE format, and only calls into unix code by making a sort of fake syscall. The "kernel" code is built in ELF format. There are a few basic reasons for doing this: * Many applications, mostly anti-cheat and anti-tamper engines, depend on our libraries actually being in PE format on disk, and matching that in memory. We used to have "fake" DLLs for this, but they weren't verisimilar enough. * Some of the important hosts for Wine have dropped support for 32-bit libraries or are going to drop it. Mac is the obvious example here, but many commercial Linux distributions also want to drop support. By limiting the surface through which code can transition between PE and Unix code, it becomes feasible to do 32-to-64 translation, where previously this was quite infeasible. * There's some demand for running Win32 debuggers under wine. These have always worked more than a little tenuously, but a couple of them are causing problems when they try to break in and unwind from Unix code. By acting like we're making actual syscalls, things work much better. Of the several dozen modules we have that currently call into Unix libraries, about half of them aren't going to use PE dependencies. Most of these have already been fully split into PE and Unix parts, including things like the socket layer and winegstreamer. This raises the question: why not just call into Unix for the other half as well? There are a few reasons: * Making fake syscalls is, like real syscalls, not cheap. It involves a full context switch into and out of Unix code. * Making callbacks from Unix code is difficult, and not cheap either. For some libraries this doesn't matter, but for others it really does. * Writing the wrappers between Unix and PE code involves some nontrivial work in itself. The smaller the interface is, the easier things are for us.
Re: Require packages to build without any configured DNS
On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote: > On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand > wrote: > > Therefore, I am in the opinion that we should let the package run its > > test as much as possible, especially considering that it's not doing > > actual network outbound connections. > > Can't we run these tests as autopkgtests? That would only move the problem elsewhere, since this creates a similar question whether such tests should need a "needs-internet" restriction for autopkgtest which might result in them being skipped in most cases. cu Adrian
Re: Require packages to build without any configured DNS
On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു +0200 +0200, Thomas Goirand wrote: Therefore, I am in the opinion that we should let the package run its test as much as possible, especially considering that it's not doing actual network outbound connections. Can't we run these tests as autopkgtests?
Re: Require packages to build without any configured DNS
On 9/6/21 4:39 PM, Mattia Rizzolo wrote: > Hi, > > during the year, a src:dnspython change made it so that any software > importing that library now requires a valid /etc/resolv.conf with at > least one nameserver configured. > > This also made it so that something between 50-100 packages now fail to > build if the build system doesn't have any working /etc/resolv.conf. I > venture to say that this is a very reasonable configuration to have in a > build system that tries to be network-disabled. > > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? > > > As the pbuilder maintainer, I've been asked to make it serve a > non-working /etc/resolv.conf just to make that bug above moot, so I'm > quite biased on the matter myself :) I already stated this during discussions on IRC, but I will reiterate here to feed the discussion. The only place where dnspython needs a working /etc/resolv.conf is testing. Mandating a non-working /etc/resolv.conf will only result in having less tests in that package, which will potentially lower the package quality insurance, rather than improving Debian. When addressing this problem, we should ask ourselves: what is it that we're actually trying to fix. IMO: not much here... There's nothing broken. Therefore, I am in the opinion that we should let the package run its test as much as possible, especially considering that it's not doing actual network outbound connections. Cheers, Thomas Goirand (zigo)
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > > So what do you suggest then? Tech-ctte as with merged-/usr? Or a > > GR? Or > > something else? > > I propose that the proponents pay the cost. In this case, it is a bit > unclear what that means precisely (which likely is the reason they > haven't done it already). At the very least though, apt install > auto-apt-proxy should continue to work on a default installation in a > sensible way. I can file a bug for auto-apt-proxy to include an apt.conf snippet saying Acquire::https::Verify-Peer false; That clearly makes it work again: you ask for auto-apt-proxy users to have connections that can be impersonated by a man in the middle by default. The above setting does that. Not verifying certificates for some users seems better than having all users not verify certificates (as no https is used at all). > In > the absence of reason not to use https, https should be preferred. As > it > happens, we figured a reason not to use https. I can find a reason not to use https for any protocol (some sites want to inspect/cache all traffic) :-) Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote: > So what do you suggest then? Tech-ctte as with merged-/usr? Or a GR? Or > something else? I propose that the proponents pay the cost. In this case, it is a bit unclear what that means precisely (which likely is the reason they haven't done it already). At the very least though, apt install auto-apt-proxy should continue to work on a default installation in a sensible way. > > * Concerns are ignored. <- This is where we are with https-default. > > It's also where we are with keep-http-as-default. I don't think https resolves any concerns. It's merely best-practice. In the absence of reason not to use https, https should be preferred. As it happens, we figured a reason not to use https. > > Change has a cost. I do not want to pay the cost for either of these > > changes. > > Then we could never change anything. Untrue. You get to choose which changes you want to pay the cost for. For instance, I want Debian to be cross buildable and bootstrappable. Holger, Mattia and a few others want Debian to be reproducible. You don't get to pay the cost for those changes. Change is possible in a way that limits cost for uninterested people. The contentious changes are the ones where the initiators fail to pay the cost. > To keep up with merged-/usr: keeping non-merged-/usr also has a cost. > Nobody wants to pay the cost for it. That is very true. With merged-/usr, I suppose most grief arises from the way the transition was (not) planned and only a minority takes issue with the goal. Helmut
Re: Require packages to build without any configured DNS
On Tue, Sep 07, 2021 at 04:41:49PM -0700, Don Armstrong wrote: > On Mon, 06 Sep 2021, Mattia Rizzolo wrote: > > It must be noted that no actual network operation happen, so this > > doesn't fall into the "no network activity" bucket. > > > > This is the bug that was filed against dnspython: > > https://bugs.debian.org/989171 > > > > Do anybody on the list have any opinion on where is the bug, on > > dnspython, or on the build environment? > > Do you know why dnspython doesn't just fall back to socket.getaddrinfo > if it can't parse /etc/resolv.conf [or maybe why python applications > using dnspython don't fall back to that if dnspython fails?] > > That seems like the right default unless you really, really need to talk > to a full-fledged DNS server directly. https://github.com/rthalley/dnspython dnspython provides both high and low level access to DNS. The high level classes perform queries for data of a given name, type, and class, and return an answer set. The low level classes allow direct manipulation of DNS zones, messages, names, and records. ... dnspython is a utility to work with DNS, /etc/hosts is thus not used. For simple forward DNS lookups, it's better to use socket.getaddrinfo() or socket.gethostbyname(). dnspython originated at Nominum where it was developed to facilitate the testing of DNS software. cu Adrian
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 13:13 +0100, Tim Woodall wrote: > This is a bit tongue in cheek, but how about these sites where the > .debs are downloaded from publish their *private* key? They openly > accept that anyone can MITM them. If you have access to the private key, you can request the CA to revoke the certificate: +--- | 4.9.1.1 Reasons for Revoking a Subscriber Certificate | | The CA SHALL revoke a Certificate within 24 hours if one or more of | the following occurs: | [...] | 3. The CA obtains evidence that the Subscriber’s Private Key | corresponding to the Public Key in the Certificate suffered a Key | Compromise +---[ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf ] So that would not be helpful. Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 8 Sep 2021, Helmut Grohne wrote: I do see the advantages of using https. I do not see how to not make it happen without breaking relevant use cases. Same with the /usr-merge. I do see the advantages. I've stopped counting the things that broke. Most recent one is the uucp FTBFS. Change has a cost. I do not want to pay the cost for either of these changes. This is a bit tongue in cheek, but how about these sites where the .debs are downloaded from publish their *private* key? They openly accept that anyone can MITM them. That way people who want to see "https" can see it. And people who want the benefits of http can, with a bit of work, simulate that. It also nicely addresses my concern which is that the next demand will be to drop http (because when you visit the site with a webbrowser users start getting a warning that the site is also available over http or something like that because the google/firefox dream seems to be that you cannot use http even where https doesn't add anything.)
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 13:53 +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote: > > Maybe we should just find out who is responsible for this decision > > and > > reassign the bug to them. The installer team maintaining d-i and > > debootstrap or the mirror team seem reasonable choices? > > We've already tried that approach on the /usr-merge and the resulting > transition is miserable. Let's not repeat that mistake. So what do you suggest then? Tech-ctte as with merged-/usr? Or a GR? Or something else? > It's the same pattern actually: > * People propose a change that does have positive effects, though > some > find the positive effects unimportant. > * Other people disagree and raise concerns. > * Concerns are ignored. <- This is where we are with https-default. It's also where we are with keep-http-as-default. > Change has a cost. I do not want to pay the cost for either of these > changes. Then we could never change anything. To keep up with merged-/usr: keeping non-merged-/usr also has a cost. Nobody wants to pay the cost for it. Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote: > Maybe we should just find out who is responsible for this decision and > reassign the bug to them. The installer team maintaining d-i and > debootstrap or the mirror team seem reasonable choices? We've already tried that approach on the /usr-merge and the resulting transition is miserable. Let's not repeat that mistake. It's the same pattern actually: * People propose a change that does have positive effects, though some find the positive effects unimportant. * Other people disagree and raise concerns. * Concerns are ignored. <- This is where we are with https-default. * Change is being implemented anyway. * Stuff breaks. <- This is where we are with /usr-merge. This is frustrating. I do see the advantages of using https. I do not see how to not make it happen without breaking relevant use cases. Same with the /usr-merge. I do see the advantages. I've stopped counting the things that broke. Most recent one is the uucp FTBFS. Change has a cost. I do not want to pay the cost for either of these changes. Helmut
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, 2021-09-08 at 13:09 +0200, Helmut Grohne wrote:
> On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> > Some users want proxy but they can configure their settings.
> > So just change "default setting for {deb,security}.debian.org"
> > is not so harmful, IMO.
>
> I fear you are putting this upside down. In reality, some sites (not
> users) want their users to use their local cache (transparently or
> not).
Then have the users install the site's CA authority that allows
inspecting and caching HTTPS traffic.
> Unfortunately, I don't see consensus for this, but at the same time I
> neither see consensus for enabling https by default. It's a matter
> that
> keeps popping up and people disagreeing on over and over again. The
> one
> thing that we have clearly understood at this point is that one size
> does not fit everyone. Either way makes some people unhappy.
Maybe we should just find out who is responsible for this decision and
reassign the bug to them. The installer team maintaining d-i and
debootstrap or the mirror team seem reasonable choices?
Ansgar
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi,
On Thu, Sep 02, 2021 at 10:22:15AM +0900, Hideki Yamane wrote:
> Some users want proxy but they can configure their settings.
> So just change "default setting for {deb,security}.debian.org"
> is not so harmful, IMO.
I fear you are putting this upside down. In reality, some sites (not
users) want their users to use their local cache (transparently or not).
> - Users can choose other mirror than https://deb.debian.org
As far as I can tell, most users don't want to make a choice here. They
want downloading packages to just work. Preferably fast. It is the
"fast" thing that you are breaking here.
> - Caching .debs from security.debian.org is not so huge, I guess
>(maybe except linux-image).
Not sure why security.d.o is singled out here. The switch is only
reasonable on the whole or not at all. And there the whole volume of
packages counts.
Enabling https by default quite simply breaks the simple recipe of
installing auto-apt-proxy. Would you agree with auto-apt-proxy's
postinst automatically editing your sources.list to drop the s out of
https? The answer repeatedly given in this thread to do so manually is
very unsatisfying.
So I actually argue for installing auto-apt-proxy by default and inside
d-i. That is in direct conflict with the proposed change here.
Unfortunately, I don't see consensus for this, but at the same time I
neither see consensus for enabling https by default. It's a matter that
keeps popping up and people disagreeing on over and over again. The one
thing that we have clearly understood at this point is that one size
does not fit everyone. Either way makes some people unhappy.
Helmut
Bug#993939: ITP: ntfs2btrfs -- converts NTFS filesystem to BTRFS
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ntfs2btrfs Version : 20210523 Upstream Authors: Mark Harmstone * URL : https://github.com/maharmstone/ntfs2btrfs * License : GPL-2-or-later Description : converts NTFS filesystem to BTRFS This is a tool which does in-place conversion of Microsoft's NTFS filesystem to the open-source filesystem Btrfs, much as btrfs-convert does for ext2. The original image is saved as a reflink copy at image/ntfs.img, and if you want to keep the conversion you can delete this to free up space.
Bug#993926: retitle 993914 RFP: gpufetch -- Simple yet fancy GPU architecture fetching tool
Package: wnpp Severity: wishlist Owner: clay stan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gpufetch Version : 0.10 Upstream Author : Dr-Noob * URL : https://github.com/Dr-Noob/gpufetch License : MIT The project homepage says that it needs cuda C compiler, which is non-free. I've just noticed this. and I'll give up packaging this package.
Re: Wine MinGW system libraries
On Wed, 08 Sep 2021 at 07:31:59 +, Bastien ROUCARIES wrote: > Simon, do you think you could implement a version of libcapasule for PE > object ? Given that libcapsule is very glibc- and ELF-specific, doesn't work properly without new glibc feature work that isn't in Debian yet (I've lost track of whether/when it got merged upstream, it might be in 2.34) and wasn't written by me, the answer is likely to be no. As far as I understand it, the PE loader used for Wine is part of Wine, so it has total control over the libraries that it loads and how it loads them. This means that if Wine developers (the experts on this codebase) have decided a libcapsule-like approach isn't feasible or isn't desirable, they are probably right. More generally, if Wine developers wanted Wine's dependency libraries to be in one version of reality, and Windows DLLs to be in a different version of reality, then there's a straightforward way to do that: use ELF .so dependency libraries, like older versions of Wine did, and don't give them a representation in the PE layer. Presumably they have put in the work to move from ELF to PE dependency libraries because it has some compelling advantage, rather than creating work for themselves for no reason! smcv
Re: Wine MinGW system libraries
Hi, Adding smcv to the thread. Le mar. 7 sept. 2021 à 23:25, Bastien ROUCARIES a écrit : > > Le mar. 7 sept. 2021 à 21:16, Zebediah Figura > a écrit : > > > > On 9/7/21 12:05 PM, Bastien ROUCARIES wrote: > > > I disagree. > > > > > > Le mar. 7 sept. 2021 à 17:48, Zebediah Figura a > > > écrit : > > > > > >> On 9/7/21 5:16 AM, Bastien Roucariès wrote: > > >>> Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : > > On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: > > > The basic problem is that applications can and often do ship with PE > > > builds of cross-platform libraries. These libraries can be ahead of > > > Wine's system libraries, behind them, or even built with custom > > >> patches. > > > Accordingly we really don't want to load "our" freetype in place of > > > "their" freetype, or "theirs" in place of "ours". But because of the > > >> way > > > the Win32 loader works, you can generally only have one DLL of a given > > > name loaded in a process, and further attempts to dlopen() [as it > > > were] > > > "libfreetype-6.dll" will return the handle to the already loaded > > > library, potentially breaking either Wine or the application. > > > > I don't know the details here, but my immediate thought when reading > > this is that you need some kind of namespace. I then found that linker > > namespaces are a thing, perhaps they would provide the solution for > > you. It sounds like the OpenGL shim loader solution listed on the > > glibc wiki might work for your use-case. Or perhaps the LD_AUDIT > > feature would also work. > > > > https://www.sourceware.org/glibc/wiki/LinkerNamespaces > > >>> I agree with pabs, implementing name space is a good solution > > >>> and will allow to be distrib friendly. > > >>> > > >>> Moreover it will be best if marking a library as wine system one could > > >> be done > > >>> post build. We will prefer to not modify upstream (like libpng) source. > > >>> > > >>> It is easier for us to apply small patch to upstream, or better in your > > >> case > > >>> to add a post link linker script or even some compiler flag that will > > >> add some > > >>> notes section to dll in order to mark it as use namespace system, or so > > >> on. > > >>> > > >>> The problem on windows side is well known as dll hell > > >>> > > >>> Renaming of the lib could be done post install. Moreover a crazy idea > > >> why not > > >>> renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll > > >> (note the > > >>> version is manadaroty) Therefore we could use upstream source. Then add > > >> a > > >>> small linker script that will rewrite the depends of libpng-2.0.0.sll > > >> to > > >>> .sll file (aka binary sed s/.dll/.sll/g). > > >>> > > >>> then add a small wraper (shim) like said pab that load the .sll library, > > >> the > > >>> best pratice will be a command tool that take the name of the sll and > > >> create > > >>> magically the dll > > >>> > > >>> Therefore from distrib point of side we only changes the way we build > > >>> the > > >>> package, it could be automated, it is scalable and it does not need to > > >> patch > > >>> package by package. Only to add some linker script magic > > >> > > >> The problem isn't particularly about detecting what is and isn't a > > >> system library; I think we can come up with a reliable heuristic for > > >> that, without even needing linker namespaces or anything. > > >> > > >> The outstanding problem seems to be more about potentially breaking > > >> applications because they see two identically named DLLs loaded in the > > >> same process. Applications can and do trawl the internal loader state, > > >> although the Win32 loader also exposes some APIs so they don't even have > > >> to. > > >> > > >> It may also be that the aforementioned heuristic is too hacky to be > > >> accepted upstream into Wine. > > >> > > > I do not propose to change the loader, i propose to change the link or > > > post > > > link stage of system library. You could rename the lib and change the > > > dépend to new name after build. So you will have an unique name per system > > > lib without changing the way you build these lib. > > > > > > It is équivalent to use a namespace resolved at late build time. > > > > > > > Ah, so what you're proposing is that we do some sort of objcopy-like > > patching at runtime, e.g. when copying the dependency into the prefix. > > > > It probably won't be easy, but it might be more feasible than modifying > > the loader. I'll look into it... > Yes sort of obcopy patching under linux it is called patchelf... > > If it work, it could be latter done in memory like paul wise suggest > implementing namespace and LT_AUDIT (but it is a long term goal) > 1. capture library loading > 2. do the patching at loading time (using the same code then patchelf > for pe replacing file read/write by mmap operation) > > And voila Simon, do you th
