Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote: > 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? I believe that the target audience is non-tech end-users. Most orgnizations already optimized their way of downloading .debs via some way (e.g. auto-apt-proxy) or another. As you point out, organizations are easily able to deviate from defaults. They're not our primary target with defaults. Laptops of end-user systems are the target, but also developers. When people gather at a place (conference, hackspace, private meetup, etc.) downloading of .debs should just work quickly by default. Many such sites could easily provide a local cache and a number even do. BSPs tend to have a blackboard with information including the local mirror to use. Seriously, how many people change their mirror when they go to a BSP? If we installed auto-apt-proxy by default, much of the local caching would just work. The thing we seem to be disagreeing on is what is more important? https by default or quick and efficient downloads? Some may think that our CDN can handle the load just fine and the effects of caching are peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8 days waiting for downloads) for me. I see that we've given up on a global network of independently-managed mirrors and that CDNs are way easier at this time. While initially CDNs had bad reliability issues, those have completely vanished in my experience. On the other hand, local caching still outperforms CDNs by a factor of 10 or so. I'd love to make it the default. Helmut
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, 2021-09-10 at 09:33 +0200, Helmut Grohne wrote: > If > we installed auto-apt-proxy by default, much of the local caching > would > just work. If you push for a local caching method to be used by default, apt should always request (In)Release.gpg from a regular mirror (not auto- discovered local cache), preferably via HTTPS; for subsequent data (which apt can verify via (In)Release) a local mirror can be used, falling back to the regular mirror when the data provided by the local cache is not correct for any reason. Especially at BSPs where people are likely to bootstrap new environments (via debootstrap, for example for building packages) we would allow downgrade attacks otherwise: (In)Release for stable releases has no Valid-Until, so any initial (In)Release file can be substituted by the cache operator for an older one which then refers to known-vulnerable packages. (And I'm not sure debootstrap even checks Valid-Until.) Ansgar
Re: Require packages to build without any configured DNS
Thomas Goirand wrote: > 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. I understood that; I'd just wanted to make it clear that while programs parsing /etc/resolv.conf should assume a nameserver on localhost if /etc/resolv.conf doesn't exist, that doesn't mean that build processes should actually require that such a nameserver be running.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
Hallo, * Michael Stone [Wed, Sep 08 2021, 07:25:26PM]: > 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 Precisely. Current handling of HTTPS on a caching proxy is either impossible or PITA for the user, as long as a such mixed behavior is not configurable. apt-cacher-ng works around that by telling users to disguise https URLs as HTTP with a special marker for protocol switch (ugly, I know). Also keep in mind that it off-loads the encryption work to the proxy, but that might be even intentional. > that also won't necessarily work on an existing proxy. Speaking at least for ACNG, my assumption was that it would support that but I was wrong. TODO created, https://salsa.debian.org/blade/apt-cacher-ng/-/issues/11 . > 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). I would make it a list of trusted proxy hosts and a special value ALL. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994032 created. Best regards, Eduard.
Re: Wine MinGW system libraries
Le jeu. 9 sept. 2021 à 07:32, Paul Wise a écrit : > > On Thu, 2021-09-09 at 00:59 -0500, Zebediah Figura wrote: > > > Unfortunately, no. We have no way of knowing the caller. > > Can the PE loading mechanism do something like inject a fake dlopen > function available only in the Wine namespace that just passes the Wine > namespace to the dlmopen function? Or the same but for each library? The problem is that windows apps particularly games try to check if mapped ram exec pages are from dll from disk and not modified in memory. Thus if we create namespace, this crappy software will stop to work except if we create or symlink a library with an unique name that the wine applications could fetch Note that windows use for libraryname only the basename not the fullpatch (zebediah could you confirm) I am proposing (for simplicity I call the problematic lib libpng that depends on libz) 1. build like usual a libpng and libz. libpng depend on linbz 2. copy libpng to libwinepng and libz to libwinez 3 use a new patchpe command (like the patchelf command) to patch the depend of libwinepng So globally a post link time namespace (it will be better on debian side than to recompile and pass flags to library). You propose: 1. build like usual a libpng and libz. libpng 2 create symlink libwinepng -> libpng, liwinez->libz 3. instruct the loader to load libwinepng privatly using namespace approach and do at run time the patchpe work I believe that your approach is technically superior but could be done on the top of my first approach and a second step. Zebediah could you please give use feedback from wine team ? If patchpe is workable (and I firmly believe it is), you could add a task to see if paul wise solution is workable and report here. Next step, will be to refine your proposal. For instance i really dislike the libpng libwinepng mapping I will prefer a mapping given as perlre and something that encode the wine ABI like s/^lib/lib-wineinternaluseABI1.0/g It will allow to create pkgconfig file for wine version of lib automatically Bastien > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
* Michael Stone [2021-09-08 19:25]: 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. apt-cacher-ng has a second mode of operation where you can prefix the source URL with the proxy URL, i.e. deb http://proxyhost:3142/deb.debian.org/debian unstable main Maybe we could introduce this as an "official" APT proxy mode, where http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy can decide whether or not to fetch via HTTPS as an implementation detail)? 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
On Fri, Sep 10, 2021 at 12:00:57PM +0200, Timo Röhling wrote: * Michael Stone [2021-09-08 19:25]: 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. apt-cacher-ng has a second mode of operation where you can prefix the source URL with the proxy URL, i.e. deb http://proxyhost:3142/deb.debian.org/debian unstable main Maybe we could introduce this as an "official" APT proxy mode, where http(s)://REPO gets replaced by http://PROXY_URL/REPO (and the proxy can decide whether or not to fetch via HTTPS as an implementation detail)? I'd much rather see something more like I proposed earlier (splitting the selection of what suites/components to install from the policy of how to obtain them) rather than further layering+confusing these two concepts within sources.list.
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote: Laptops of end-user systems are the target, but also developers. When people gather at a place (conference, hackspace, private meetup, etc.) downloading of .debs should just work quickly by default. Many such sites could easily provide a local cache and a number even do. BSPs tend to have a blackboard with information including the local mirror to use. Seriously, how many people change their mirror when they go to a BSP? If we installed auto-apt-proxy by default, much of the local caching would just work. I think you'd get a lot of pushback on installing auto-apt-proxy by default. If that's a proposal, make it seperately and not in this thread. The thing we seem to be disagreeing on is what is more important? https by default or quick and efficient downloads? Some may think that our CDN can handle the load just fine and the effects of caching are peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8 days waiting for downloads) for me. I see that we've given up on a global network of independently-managed mirrors and that CDNs are way easier at this time. While initially CDNs had bad reliability issues, those have completely vanished in my experience. On the other hand, local caching still outperforms CDNs by a factor of 10 or so. I'd love to make it the default. I use a cache out of habit and to be a good netizen, but my internet connection is fast enough these days that it's basically a noop at best and a slight slowdown at worst. I had to move the cache from slow/cheap spinning disk to reasonably fast SSD to get to that point. If you're downloading the same stuff over and over (e.g., for testing or somesuch) it can be a big win, especially for VMs on a virtualized network connection, or if you're managing a large infrastructure, but for normal use with a couple of instances? It's just not worth the trouble.
Epoch bump request for ksh
Hi As a result of a revert of v2020 of ksh last year, the current version on sid for ksh is as follows: 2020.0.0+really93u+20120801-10 With the next upgrade, we're looking to move to the 93u+m community maintained distribution that has a different versioning scheme (starting with 1.0.0-beta.1). Without bumping up the epoch, we can possibly version it as follows, by using a newer date prefix: 20210510-93u+m-1.0.0~beta.1-1 However, I would like to request feedback to move to the following version with a bump of the epoch: 1:93u+m-1.0.0~beta.1-1 Thanks, Anuradha
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 05:18:13PM +0530, Anuradha Weeraman wrote: > As a result of a revert of v2020 of ksh last year, the current version > on sid for ksh is as follows: > > 2020.0.0+really93u+20120801-10 > > With the next upgrade, we're looking to move to the 93u+m community > maintained distribution that has a different versioning scheme (starting > with 1.0.0-beta.1). I was curious about why, and while I'm neither a ksh dev or user, in the context of Debian packaging it doesn't seem so simple. I'm trying not to step on your toes, or dredge up interpersonal conflict. https://github.com/att/ast/issues/1466 The impression I got is that there are at least 3 projects making claim to "ksh93" going forwards. 93u+2012 is the last known stable, compatible version that has been reverted to and, crucially, has been shipped in all Debian stable releases. There seems to be community demand and distro maintainers support for collaborating on keeping the build system working on modern systems, which will not be merged back into the att repo - do you know if this has happened, where the fork can be found? https://tracker.debian.org/pkg/ksh Then there appears to be this 93u+m project publishing essentially v2020 as 1.0.0 beta, tagged as 'v1.0.0-beta.1'. It's release notes say "This new fork is called ksh 93u+m as a permanent nod to its origin". It is making more invasive fixes to the codebase and trimming unused components, but there are some concerns noted over its backwards compatibility with 40 years of scripts. https://github.com/ksh93/ksh > However, I would like to request feedback to move to the following > version with a bump of the epoch: > > 1:93u+m-1.0.0~beta.1-1 1) If there are possible edge-case compatibility issues, have you considered a new source package and use of the alternatives system? This would let Debian users choose between the two options for their use case - maintaining existing systems, or writing new ksh scripts. 2) If you do go ahead with switching to the community distribution, then "93u+m" is part of the name, not the version number, so I'd suggest: 1:1.0.0~beta.1-1 signature.asc Description: PGP signature
Bug#994039: ITP: mirrorbits -- Geographical download redirector for distributing files efficiently across a set of mirrors.
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: mirrorbits Version : 0.5.1+git20210123.eeea0e0-1 Upstream Author : Ludovic Fauvet * URL : https://github.com/etix/mirrorbits * License : Expat Programming Lang: Go Description : Geographical download redirector for distributing files efficiently across a set of mirrors. Mirrorbits Mirrorbits is a geographical download redirector written in Go (https://golang.org) for distributing files efficiently across a set of mirrors. It offers a simple and economic way to create a Content Delivery Network layer using a pure software stack. It is primarily designed for the distribution of large-scale Open-Source projects with a lot of traffic. . Main Features * Blazing fast, can reach 8K QPS on a single laptop * Easy to deploy and maintain, everything is packed in a single binary * Automatic synchronization with the mirrors over rsync or FTP * Response can be either JSON or HTTP redirect * Support partial repositories * Complete checksum / size control * Realtime monitoring and reports * Disable misbehaving mirrors without human intervention * Realtime decision making based on location, AS number and defined rules * Smart load-balancing over multiple mirrors in the same area to avoid hotspots * Ability to adjust the weight of each mirror * Limit access to a country, region or ASN for any mirror * Clustering (multiple mirrorbits instances) * High-availability using redis-sentinel * Automatically fix timezone offsets for broken mirrors * Realtime statistics per file / mirror / date * Realtime reconfiguration * Seamless binary upgrade (aka zero downtime upgrade) * Mirmon (http://www.staff.science.uu.nl/~penni101/mirmon/) support * Full IPv6 support * more... . Is it production ready? Yes! Mirrorbits has served billions of files already and is known to be running in production at VideoLAN (http://www.videolan.org) to distribute VLC media player (http://www.videolan.org/vlc/) since April 2014
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 02:25:32PM +0100, Phil Morrell wrote: > On Fri, Sep 10, 2021 at 05:18:13PM +0530, Anuradha Weeraman wrote: > Then there appears to be this 93u+m project publishing essentially v2020 > as 1.0.0 beta, tagged as 'v1.0.0-beta.1'. It's release notes say "This > new fork is called ksh 93u+m as a permanent nod to its origin". It is > making more invasive fixes to the codebase and trimming unused > components, but there are some concerns noted over its backwards > compatibility with 40 years of scripts. > > https://github.com/ksh93/ksh To give some context: The development of v2020 of ksh that took place on github.com/att/ast was rolled back last year, as it was primarily based on the less stable ksh93v- as a starting point which resulted in regressions and performance problems. The "att/ast" repository on which the development was taking was reset back to pre-2020 and the development has discontinued. ksh93u+/v- itself is not being maintained since the departure of Dr. Korn from AT&T circa 2014. ksh93u+m was a reboot attempt by Martijn Dekker et al. to build upon the last stable 93u+ release (not on v2020, apart from some cherry picked patches). This work has been taking place for over a year at this point, with the objective of making incremental changes, by fixing long standing issues, consolidating patches from RedHat, OpenSUSE, Solaris etc, removing unused code, fixing the build system, and testing across different UNIX variants. The distribution has come a long way, and the upstream maintainers have been carefully curating fixes and maintaining backwards compatibility. > 1) If there are possible edge-case compatibility issues, have you > considered a new source package and use of the alternatives system? This > would let Debian users choose between the two options for their use case > - maintaining existing systems, or writing new ksh scripts. This was the approach briefly, when we introduced ksh93 as separate package for those who didn't want to upgrade to ksh2020 and the issues that came with it. Since the revert of ksh2020 upstream, it was also reverted in src:ksh, making the need for a separate ksh93 unnecessary, and so has been removed from the archive. ksh93u+ is incremental, and backwards compatibility is considered seriously and further validated with a test suite. > 2) If you do go ahead with switching to the community distribution, then > "93u+m" is part of the name, not the version number, so I'd suggest: > > 1:1.0.0~beta.1-1 It does make sense to differentiate with the 93u+m prefix. Amending the proposed version below: 1:93u+m-1.0.0~beta.1-1 -- Anuradha
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > The only thing I could see that would be a net gain would be to generalizes > sources.list more. Instead of having a user select a specific protocol and > path, allow the user to just select high-level objects. Make this a new > pseudo-protocol for backward compatibility, and introduce something like > deb apt:// suite component[s] > so the default could be something like > deb apt:// bullseye main > deb apt:// bullseye/updates main > then the actual protocols, servers, and paths could be managed by various > plugins and overridden by configuration directives in apt.conf.d. For In this scheme the Debian bullseye main repo has the same 'URI' as the Darts bullseye main repo. So, you would need to at least include an additional unique identifier of the likes of Debian and Darts, but who is to assign those URNs? (Currently we are piggybacking on the domain name system for this) Also, but just as an aside, whatever clever system you think of apt could be using, you still need a rather simple system for the likes of tools which come before apt like the installers/bootstrappers as they are not (all) using apt, especially not in the very early stages, and a mapping between them. > If someone wants to use tor by default but fall back to https if it's > unreachable, they can do that. If someone wants to use a local proxy via > http but https if they're not on their local network, they can do that. New > installations could default to https, existing installations can keep doing You can do most of the fallback part with the mirror method backed by a local file. It is of no concern to apt how that file comes to be, so you could create it out of a massive amount of options or simply by hand. I do think if the creation is tool-based it shouldn't be apt as I envision far too many unique snowflakes for a one-size-fits-all approach. (The Tor to https fallback can be done already if we talk onion services to others. You can't fall out of Tor – or redirect into it – through as that would allow bad actors to discover who you are/that you have an operational tor client installed. proxy configuration you can already change programmatically on the fly – a job auto-apt-proxy implements –, changing the mirror file with a hook from your network manager would be equally easy.) > their thing, and a plugin like auto-apt-proxy can override defaults to do > something more complicated, using more policy-friendly .d configurations > rather than figuring out a way to rewrite some other package's configuration > file. JFTR: auto-apt-proxy has nothing to do with sources. It is true that apt-cacher-ng (and perhaps others) have a mode of operation in which you prefix the URI of your (in that case caching) proxy to the URI of the actual repo, but that isn't how a proxy usually operates and/or is configured. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 10.09.21 01:46, Paul Wise wrote: Another important argument is that it creates a dependency on third-party commercial CDNs, and their *continued* sponsorship. This dependency on external providers is unavoidable, Debian definitely cannot afford to run our own CDN at the scale needed to support our existing userbase. For example the security mirrors struggled with Linux kernel security updates, so security.d.o switched to a commercial CDN. Also, we are dependent on continued sponsorship for all of our infrastructure, paying for all of our hosting is likely not feasible. Yes -- and mirrors have traditionally been provided by third parties. What is new about the CDNs is that there are rather few of those, and this centralization aspect is what worries me. Personally I'd like to see a larger variety of Debian delivery mechanisms; copy Debian/snapshot to archive.org, create a multi-distro FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p mirror, use IPFS and content oriented networking etc. Michael Stone's apt://debian idea seems like a good way to move in that direction while adding protocol agility. Yes, absolutely -- and we especially want to have a better solution for containers, because my expectation is that a large fraction of our traffic is just people not bothering to set up caching. Simon
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: The only thing I could see that would be a net gain would be to generalizes sources.list more. Instead of having a user select a specific protocol and path, allow the user to just select high-level objects. Make this a new pseudo-protocol for backward compatibility, and introduce something like deb apt:// suite component[s] so the default could be something like deb apt:// bullseye main deb apt:// bullseye/updates main then the actual protocols, servers, and paths could be managed by various plugins and overridden by configuration directives in apt.conf.d. For In this scheme the Debian bullseye main repo has the same 'URI' as the Darts bullseye main repo. So, you would need to at least include an additional unique identifier of the likes of Debian and Darts, but who is to assign those URNs? (Currently we are piggybacking on the domain name system for this) I have no idea what darts is, so I don't have an answer. :) Also, but just as an aside, whatever clever system you think of apt could be using, you still need a rather simple system for the likes of tools which come before apt like the installers/bootstrappers as they are not (all) using apt, especially not in the very early stages, and a mapping between them. I'm not sure why you think I need that? The goal of my musings is to separate the definition of what set of debian packages to use from the decision of how to get those packages *when using apt*, so that there are fewer things to consider in the common case, and to allow new capabilities in uncommon cases. If someone's using some other tool, why would anyone assume that the same configuration syntax would work? Just use the same configuration file you use now, and ignore all of this. If you want configurations to match across tools, then ignore all of this again and keep the same sources.list syntax you're already using that presumably does what you want. If someone wants to use tor by default but fall back to https if it's unreachable, they can do that. If someone wants to use a local proxy via http but https if they're not on their local network, they can do that. New installations could default to https, existing installations can keep doing You can do most of the fallback part with the mirror method backed by a local file. It is of no concern to apt how that file comes to be, so you could create it out of a massive amount of options or simply by hand. I do think if the creation is tool-based it shouldn't be apt as I envision far too many unique snowflakes for a one-size-fits-all approach. The intent would be to make it easier to plug other tools into apt, not to have the apt codebase do everything. their thing, and a plugin like auto-apt-proxy can override defaults to do something more complicated, using more policy-friendly .d configurations rather than figuring out a way to rewrite some other package's configuration file. JFTR: auto-apt-proxy has nothing to do with sources. It is true that apt-cacher-ng (and perhaps others) have a mode of operation in which you prefix the URI of your (in that case caching) proxy to the URI of the actual repo, but that isn't how a proxy usually operates and/or is configured. I have no idea what you're saying here.
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 07:37:55PM +0530, Anuradha Weeraman wrote: > > 2) If you do go ahead with switching to the community distribution, then > > "93u+m" is part of the name, not the version number, so I'd suggest: > > > > 1:1.0.0~beta.1-1 > > It does make sense to differentiate with the 93u+m prefix. Amending the > proposed version below: > > 1:93u+m-1.0.0~beta.1-1 Correction: rushed the last email, I meant to say that I agree that 93u+m is not part of the version per se. I just thought that it would be good to include, just for specificity. However, amending the proposed version as suggested since it makes sense: 1:1.0.0~beta.1-1 thanks Anuradha
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote: > On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: > > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > > > The only thing I could see that would be a net gain would be to > > > generalizes > > > sources.list more. Instead of having a user select a specific protocol and > > > path, allow the user to just select high-level objects. Make this a new > > > pseudo-protocol for backward compatibility, and introduce something like > > > deb apt:// suite component[s] > > > so the default could be something like > > > deb apt:// bullseye main > > > deb apt:// bullseye/updates main > > > then the actual protocols, servers, and paths could be managed by various > > > plugins and overridden by configuration directives in apt.conf.d. For > > > > In this scheme the Debian bullseye main repo has the same 'URI' as the > > Darts bullseye main repo. So, you would need to at least include an > > additional unique identifier of the likes of Debian and Darts, but > > who is to assign those URNs? > > (Currently we are piggybacking on the domain name system for this) > > I have no idea what darts is, so I don't have an answer. :) "Darts" was just a play on "bullseye". It is not hard to imagine a repository which has the same suite and component(s) but is not Debian itself. As a pseudo-random [= its in an other topic here] real example you can take Wine (https://dl.winehq.org/wine-builds/debian/). So to what is "deb apt:// bullseye main" referring? Debian or Wine? And to pre-empt the most common response: As an apt dev I can assure you that we won't accept a solution involving "I am on Debian, so it means Debian" as that is impossible to correctly guess programmatically (for example on derivatives using a small overlay repo). > > Also, but just as an aside, whatever clever system you think of apt > > could be using, you still need a rather simple system for the likes of > > tools which come before apt like the installers/bootstrappers as they > > are not (all) using apt, especially not in the very early stages, and > > a mapping between them. > > I'm not sure why you think I need that? The goal of my musings is to Because this thread started with the idea to switch the default of d-i and co to another URI. If you target only apt then you still need a solution for d-i and a way to convert whatever d-i had into what apt gets in the end (of the installation). The configuration option which only works with apt tools already exists in the form of the mirror method… > > > their thing, and a plugin like auto-apt-proxy can override defaults to do > > > something more complicated, using more policy-friendly .d configurations > > > rather than figuring out a way to rewrite some other package's > > > configuration > > > file. > > > > JFTR: auto-apt-proxy has nothing to do with sources. It is true that > > apt-cacher-ng (and perhaps others) have a mode of operation in which you > > prefix the URI of your (in that case caching) proxy to the URI of the > > actual repo, but that isn't how a proxy usually operates and/or is > > configured. > > I have no idea what you're saying here. And I have no idea if you know what you are talking about. auto-apt-proxy already uses an interface apt provides to configure the proxy at runtime. It isn't in the business of modifying sources.list nor has it any interest in that. So you using it as an example for a plugin who could use your proposed scheme to modify the sources at runtime makes no sense. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 08:02:42PM +0200, David Kalnischkies wrote: On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote: On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote: > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote: > > The only thing I could see that would be a net gain would be to generalizes > > sources.list more. Instead of having a user select a specific protocol and > > path, allow the user to just select high-level objects. Make this a new > > pseudo-protocol for backward compatibility, and introduce something like > > deb apt:// suite component[s] > > so the default could be something like > > deb apt:// bullseye main > > deb apt:// bullseye/updates main > > then the actual protocols, servers, and paths could be managed by various > > plugins and overridden by configuration directives in apt.conf.d. For > > In this scheme the Debian bullseye main repo has the same 'URI' as the > Darts bullseye main repo. So, you would need to at least include an > additional unique identifier of the likes of Debian and Darts, but > who is to assign those URNs? > (Currently we are piggybacking on the domain name system for this) I have no idea what darts is, so I don't have an answer. :) "Darts" was just a play on "bullseye". It is not hard to imagine a repository which has the same suite and component(s) but is not Debian itself. As a pseudo-random [= its in an other topic here] real example you can take Wine (https://dl.winehq.org/wine-builds/debian/). So to what is "deb apt:// bullseye main" referring? Debian or Wine? And to pre-empt the most common response: As an apt dev I can assure you that we won't accept a solution involving "I am on Debian, so it means Debian" as that is impossible to correctly guess programmatically (for example on derivatives using a small overlay repo). I'd considered adding a scope to the model, e.g., apt://debian.org but removed it for simplicity. If that was a desired feature then there'd either have to be some sort of well-known path or such a distribution would need to provide a policy plugin for that scope. Alternatively, they could just use the existing http/https/whatever syntax in sources.list for their overlay if they didn't want to bother. Same for third party repos. > > their thing, and a plugin like auto-apt-proxy can override defaults to do > > something more complicated, using more policy-friendly .d configurations > > rather than figuring out a way to rewrite some other package's configuration > > file. > > JFTR: auto-apt-proxy has nothing to do with sources. It is true that > apt-cacher-ng (and perhaps others) have a mode of operation in which you > prefix the URI of your (in that case caching) proxy to the URI of the > actual repo, but that isn't how a proxy usually operates and/or is > configured. I have no idea what you're saying here. And I have no idea if you know what you are talking about. auto-apt-proxy already uses an interface apt provides to configure the proxy at runtime. It isn't in the business of modifying sources.list nor has it any interest in that. So you using it as an example for a plugin who could use your proposed scheme to modify the sources at runtime makes no sense. The concern I was responding to was that switching to https breaks the case of using auto-apt-proxy to cache the transaction. Just turning the proxy on and off isn't sufficient if the default sources.list uses https instead of http--you'd currently have to both turn the proxy on *and* change sources.list from http to https. Hence my musings on whether it's possible/desirable to separate the configuration of what to use as a transport from the configuration of what repository is desired. More generally, if we're talking about changing the default way that people interact with debian it just seems like a good time to ponder whether specifying sources the same way we did in 1998 makes sense given how many changes there have been to expectations about how we use internet resources. Maybe the answer is yes, and I'm not arguing that there has to be a change or that what I threw out as a possibility is the right answer, but it does seem worth considering.
Re: Require packages to build without any configured DNS
On Wed, Sep 08, 2021 at 09:01:31AM -0700, Josh Triplett wrote: >... > 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. How libraries implement a standard high-level C interface is not necessarily relevant for how a DNS library implements a low-level interface. > 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. It is debatable whether this is a feature or a bug. Having to configure a nameserver when you want DNS is less surprising than software automatically using nameservers like 127.0.0.1 or 8.8.8.8 when none is configured. > 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. >... Depending on and configuring a normal DNS server might not happen in practice, since the build process running as a normal user would have to configure and manually start it running on a non-privileged port. Trying to resolve DNS addresses on the internet during the build is not permitted. > - Josh Triplett cu Adrian
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 07:37:55PM +0530, Anuradha Weeraman wrote: > ksh93u+m was a reboot attempt by Martijn Dekker et al. to build upon > the last stable 93u+ release (not on v2020, apart from some cherry > picked patches). This work has been taking place for over a year at this > point, with the objective of making incremental changes, by fixing long > standing issues, consolidating patches from RedHat, OpenSUSE, Solaris > etc, removing unused code, fixing the build system, and testing across > different UNIX variants. The distribution has come a long way, and the > upstream maintainers have been carefully curating fixes and maintaining > backwards compatibility. Ah I see, thanks for correcting my mistake about which project is which. That way round I completely agree there's no need to use alternatives and personally see no issue with bumping the epoch accordingly. signature.asc Description: PGP signature
Bug#994071: ITP: aws-nuke -- Nuke a whole AWS account and delete all its resources.
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: aws-nuke Version : 2.16.0-1 Upstream Author : reBuy reCommerce GmbH * URL : https://github.com/rebuy-de/aws-nuke * License : Expat Programming Lang: Go Description : Nuke a whole AWS account and delete all its resources. Remove all resources from an AWS account. . Be aware that aws-nuke is a very destructive tool, hence be very careful while using it. Otherwise can cause production data deletion. . As an advise try to not run this application on any AWS account, where cannot be afforded to lose all resources. By default aws-nuke only lists all resources to delete. It's necessary to add --no-dry-run to actually delete resources. . This tool retries deleting all resources until all specified ones are deleted or until there are only resources with errors left. AWS Credentials There are two ways to authenticate aws-nuke. There are static credentials and profiles. The later one can be configured in the shared credentials file or the shared config file.
Bug#994074: ITP: kubernetes-split-yaml -- Split a giant yaml file into one file per Kubernetes resource
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name: kubernetes-split-yaml Version : 0.3.0-1 Upstream Author : Frederik Mogensen * URL : https://github.com/mogensen/kubernetes-split-yaml * License : Expat Programming Lang: Go Description : Split the 'giant yaml file' into one file pr kubernetes resource This program can be usefull in case it's necessary to split a big Kubernetes yaml manifest files into small ones. . It supports filters using namespaced hierarchy, Kubernetes objects starting with a word or Deployments and StatefulSets types.
Re: Wine MinGW system libraries
Disclaimer: I know precisely zero of the details here nor
if the PE loader can support any of the below features.
On Fri, 2021-09-10 at 09:23 +, Bastien ROUCARIES wrote:
> The problem is that windows apps particularly games try to check if
> mapped ram exec pages are from dll from disk and not modified in
> memory.
The fake dlopen could presumably be provided by an on-disk DLL?
The PE loader would just load the fake dlopen DLL first, like
glibc does when you set the LD_PRELOAD environment variable.
> You propose:
I'm not proposing any on-disk symlinks, renaming DLLs or any other
changes to any PE DLLs, just loading into memory like dlmopen.
The solution I'm thinking of looks something like this:
src:libpng -> libpng16-16:$winarch -> /usr/lib/$wintriplet/libpng16.dll
(requires Debian to support cross-only, partial and Windows arch types)
PE loader sets up in-memory Wine namespace.
PE loader loads into Wine namespace:
/usr/lib/$windowstriplet/wine/fake-dlopen.dll
PE loader loads Wine dependencies into Wine namespace.
Some of the Wine dependencies call the Windows equivalent of dlopen,
which resolves to the fake dlopen equivalent within the namespace,
which calls the Windows equivalent of dlmopen("Wine", dll), which makes
the PE loader load those libraries into the Wine namespace.
PE loader finishes loading Wine dependencies and proceeds loading the
PE file and its dependencies into the default namespace.
Windows apps check mapped RAM pages and they show up correctly.
The main issue would be that apps could check they run in Wine.
OTOH the PE loader could also just hide the pages somehow?
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
