Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo
Hi, On 04.04.24 20:51, Bill Allombert wrote: I still think we should allow Autobuild: no as an escape hatch. If we want to require non-free package to be autobuildable, we should be more explicit about it (and probably require more feedback from debian-devel). There is no requirement for non-free to be autobuildable today. This change also does not introduce this, except for everything that is to be built on official builders to not require network access. There are even two stages of allowlisting today (file-based and the dsc field). Kind regards Philipp Kern
Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free
Hi, On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote: > On 2024-04-02 09:21, Sean Whitton wrote: > > Hello, > > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote: > > > > > The debian policy, section 4.9, forbids network access for packages in > > > the main archive, which implicitly means they are authorized for > > > packages in contrib and non-free (and non-free-firmware once #1029211 is > > > fixed). > > > > > > This gives constraints on the build daemons infrastructure and also > > > brings some security concerns. Would it be possible to extend this > > > restriction to all archives? > > > > We need to know if this is going to break existing packages and allow > > some input from their maintainers. Are you able to prepare a list of > > the affected packages? > > Fair enough. I can work on that, but help would be welcome as my > resources are limited. I did a test rebuild of contrib, non-free and non-free-firmware packages in sid with both stable sbuild schroot and unshare backends and could not find a difference in build success (i.e. what failed failed in both, what succeeded succeeded in both). Kind regards Philipp Kern
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On 1/21/2020 4:50 PM, Sam Hartman wrote: >>>>>> "Philipp" == Philipp Kern writes: > > Philipp> I'm told it was broken by the upgrade of Apache - apparently it > can no > Philipp> longer do per path client certificate authentication. There is a > Philipp> pending RT ticket from DSA to fix that but I don't think there is > Philipp> anything I can do at the moment - except turn on SSO for the > whole > Philipp> vhost. Maybe that could even be a workaround for now and we could > Philipp> check if someone is annoyed by that. :) > > TLS dropped the facilities necessary to do that. > Ultimately you'll need a vhost for stuff that requires client certs and > other vhosts that do not. > The user experience of having a site request client certs when you don't > have one to give is really bad in some browsers. > > Client certs really kind of are the unloved step child of web > authentication. Yeah, so Julien helpfully just created auth.buildd.debian.org (thanks for that!). I'm going to spend some time on that tomorrow. That being said, tracker, nm and contributors already moved to request client certificates on the main host. I find the UI problematic when you actually have a cert, as it will show a problem. In enterprise environments you can push a policy to not ask about which certificate to use but for privacy reasons it is still explicit in the normal case. And yes, the correct approach would be something like OAuth2. Or use client certificates with some sort of CLI. :/ Kind regards Philipp Kern
Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On January 20, 2020 10:59:48 Drew Parsons wrote: Has the self-service wannabuild giveback script been disabled? It's now rejecting connections, e.g. https://buildd.debian.org/auth/giveback.cgi?pkg=ga&suite=sid&arch=armel generates Forbidden You don't have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication. Apache Server at buildd.debian.org Port 443 My SSO is otherwise working fine, e.g. triggering debci tests at https://ci.debian.net/user I'm told it was broken by the upgrade of Apache - apparently it can no longer do per path client certificate authentication. There is a pending RT ticket from DSA to fix that but I don't think there is anything I can do at the moment - except turn on SSO for the whole vhost. Maybe that could even be a workaround for now and we could check if someone is annoyed by that. :) Kind regards Philipp Kern
Re: Guidance on solving the username namespacing problem
On 2020-01-05 23:33, Philipp Kern wrote: And then the following (in spirit) to base-passwd to make the systemd allocation explicit: --- a/README +++ b/README @@ -32,6 +32,9 @@ registry of allocations. Reserved uids: uid | name | description --+---+--- +61184 | | reserved for systemd dynamic users + - | | +63433 | | 63434 | netplan | netplan 64000 | ftn | fidogate 64001 | mysql | mysql-server I'd still like to hear from the systemd maintainers about their opinion about the UID space shift and slight reduction, of course. So it looks like this is effectively groundhog day for them as Michael pointed me to [1] where the same thing was discussed before. Given the DynamicUser design[2] I'd still assume that where it is in the UID space effectively does not matter much, it's fungible. There will be effectively no files permanently owned by those UIDs because the filesystem locations where the services can write are restricted and tightly managed. So dear systemd maintainers, how would you think about changing the UID space to the above? 2249 UIDs vs. 4335 UIDs means that the space is effectively halved, which might be concerning. It is unfortunate that this cannot be changed at runtime, but if we get bug reports about this I feel like it should be possible to make it take multiple ranges instead. Apart from where the space needs to be located it does not seem like there are strong reasons to prefer systemd's current range over any other. I don't know what happens if that range is changed across a package upgrade, though. Presumably the hashes would be different so actually making the change might be tricky. Kind regards and thanks Philipp Kern [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905817 [2] http://0pointer.net/blog/dynamic-users-with-systemd.html
Re: Guidance on solving the username namespacing problem
t; +username. > > 1000-5: > Dynamically allocated user accounts. By default ``adduser`` will And then the following (in spirit) to base-passwd to make the systemd allocation explicit: > --- a/README > +++ b/README > @@ -32,6 +32,9 @@ registry of allocations. > Reserved uids: > uid | name | description > --+---+--- > +61184 | | reserved for systemd dynamic users > + - | | > +63433 | | > 63434 | netplan | netplan > 64000 | ftn | fidogate > 64001 | mysql | mysql-server I'd still like to hear from the systemd maintainers about their opinion about the UID space shift and slight reduction, of course. Kind regards and thanks Philipp Kern
Re: Guidance on solving the username namespacing problem
Hey, thanks, Sam, Simon and Russ! That was all very helpful! Much appreciated! [Adding the systemd maintainers to the Cc for Simon's question below.] On 1/4/2020 5:08 PM, Simon McVittie wrote: > On Sat, 04 Jan 2020 at 13:52:51 +0100, Philipp Kern wrote: >> now that we are talking again about standardizing user creation using >> sysusers, I wonder if you could give me any guidance on how to attack >> the Debian system user namespacing problem. > > It's a good reminder, but I think the naming convention for system users > is mostly orthogonal to whether they're created by adduser, useradd, > systemd-sysusers or something else. (But see below for DynamicUser.) Correct. I think it mostly serves as a point of transition - when you have to touch it anyhow, you might as well be able to rename the user. (Although in many cases it is probably rather tricky.) >> OpenBSD rather successfully standardized on the underscore prefix to >> eliminate this conflict altogether. I would like that we recommend the >> same thing. > > I agree that's a good convention for new system users (better than > debian- or Debian-, and a lot better than having no particular prefix), > particularly now that apt creates _apt on basically every Debian-derived > system. > >> The main question that has been raised was how to manage the migration. >> I think the priority should be on stopping the bleeding and new users >> should follow a consistent scheme > > I agree, and I don't think the absence of a migration path for existing > system users like messagebus and systemd-coredump should prevent us > from encouraging the OpenBSD underscore thing for new system users > like _apt and _flatpak. > > I maintain several game servers that use undesirable usernames like > Debian-openarena, which might make good test subjects for automatic > migration to names like _openarena in relatively unimportant packages > (we shouldn't be using more important packages like dbus as our test > subjects). After successfully prototyping it in a couple of packages, > the right place for it would probably be debhelper or init-system-helpers. > > The thing to do during migration would probably be to add a second user > with the same uid and other details, but a different username (like > useradd --non-unique); then optionally remove the original user record, > leaving only the new name. I fear that we might need a local policy hook for migrations. If we end up renaming users that are actively referenced elsewhere, there might be cleanup tasks that need to be performed in lockstep. At the same time I'd strongly suggest that we do not go the way of distinguishing between the old user already being present on a machine and a new package install. That's a divergence that becomes actively harmful when you try to manage a set of machines. > On Sat, 04 Jan 2020 at 13:55:40 +0100, Philipp Kern wrote: >> A more bold move would be to tell daemon packagers to use DynamicUser >> where feasible and only allocate more permanent users if there's a need >> for it. > > I think this is *almost* orthogonal to how those users are named. > > The only way in which DynamicUser affects the naming policy is that if > foo-bar.service uses DynamicUser=yes and does not specify a User, the > default is foo-bar. /lib/systemd/system/fwupd-refresh.service is currently > the only example on my laptop. > > For units with a long, namespaced name like fwupd-refresh.service, > flatpak-system-helper.service and quake2-server.serice, this is probably > good enough in practice, even though in principle these names might collide. > > Possible routes: > > - leave these units with behaviour that does not follow the recommendation, > reasoning that if they have fairly long names it won't actually be a > practical problem > > - recommend that units with DynamicUser=yes should specify a User and Group > that fit the naming convention, for example DynamicUser=yes, > User=_fwupd-refresh > > - ask the systemd Debian maintainers to patch systemd so that it defaults > to the equivalent of User=_fwupd-refresh instead (note that this > behaviour change is in principle an API break which could conceivably > make services that work in other distributions fail to work in Debian, > although probably it would work fine in practice) > > - ask systemd upstream to make that change (they could probably be persuaded > that the OpenBSD underscore thing is a good convention; same notes about > this being a behaviour change) > > - avoid DynamicUser=yes As I see it it isn't even guaranteed that services will have a dash, which is quite unfortunate. That would already make the
Re: Guidance on solving the username namespacing problem
(And then my broken keyboard driver caused this to be sent prematurely. But alas, it's out now.) On 1/4/2020 1:52 PM, Philipp Kern wrote: > [Please cc me on replies as I am not currently subscribed to the list.] > > now that we are talking again about standardizing user creation using > sysusers, I wonder if you could give me any guidance on how to attack > the Debian system user namespacing problem. > > There are some well-known usernames like "root" that are a given for an > organization to block. But there are many usernames dynamically created > by applications. DynamicUser would solve part of the problem, but some > services need to persist data and sometimes it is useful to reference a > fixed identity even outside of a filesystem context (e.g. in iptables > rules). At my organization we had collisions with regular usernames - > e.g. a user legitimately called themselves "bind" because part of their > name was "Bin". Debian does not maintain a complete list of such > usernames and it is even hard to compute from the packages right now, > given that the users are created from maintainer scripts and sometimes > are even configured from Debconf (which is another arbitrary indirection). > > OpenBSD rather successfully standardized on the underscore prefix to > eliminate this conflict altogether. I would like that we recommend the > same thing. > > The main question that has been raised was how to manage the migration. > I think the priority should be on stopping the bleeding and new users > should follow a consistent scheme, but I understand how without a > migration plan we just end up with "one more scheme" (even if it might > be the most popular now except using none at all[1]). > > I tried to raise this issue in [2] a year ago, but I think I don't know > how to even start drafting a policy snippet about this. Would it be > sufficient to just mandate "In order to avoid collisions with accounts > created by the system administrator, usernames created by packages > should start with an underscore." (assuming we could get a rough > consensus for something like that) in 9.2.1 for now? Or is this > effectively infeasible until we come up with a good migration story? A more bold move would be to tell daemon packagers to use DynamicUser where feasible and only allocate more permanent users if there's a need for it. In the end what I'm looking for is input from the policy editors on how to possibly approach this. Especially as AIUI policy is supposed to document current consensus rather than necessarily set the standards. Kind regards Philipp Kern
Guidance on solving the username namespacing problem
[Please cc me on replies as I am not currently subscribed to the list.] Hi, now that we are talking again about standardizing user creation using sysusers, I wonder if you could give me any guidance on how to attack the Debian system user namespacing problem. There are some well-known usernames like "root" that are a given for an organization to block. But there are many usernames dynamically created by applications. DynamicUser would solve part of the problem, but some services need to persist data and sometimes it is useful to reference a fixed identity even outside of a filesystem context (e.g. in iptables rules). At my organization we had collisions with regular usernames - e.g. a user legitimately called themselves "bind" because part of their name was "Bin". Debian does not maintain a complete list of such usernames and it is even hard to compute from the packages right now, given that the users are created from maintainer scripts and sometimes are even configured from Debconf (which is another arbitrary indirection). OpenBSD rather successfully standardized on the underscore prefix to eliminate this conflict altogether. I would like that we recommend the same thing. The main question that has been raised was how to manage the migration. I think the priority should be on stopping the bleeding and new users should follow a consistent scheme, but I understand how without a migration plan we just end up with "one more scheme" (even if it might be the most popular now except using none at all[1]). I tried to raise this issue in [2] a year ago, but I think I don't know how to even start drafting a policy snippet about this. Would it be sufficient to just mandate "In order to avoid collisions with accounts created by the system administrator, usernames created by packages should start with an underscore." (assuming we could get a rough consensus for something like that) in 9.2.1 for now? Or is this effectively infeasible until we come up with a good migration story? Kind regards Philipp Kern [1] https://people.debian.org/~pkern/permanent/userlist.txt [2] https://lists.debian.org/debian-devel/2019/02/msg00131.html and following
Mismatch between documentation and reality: Valid-Until
Hi, dak and https://wiki.debian.org/RepositoryFormat seem to disagree on the definition of the Valid-Until field. dak writes "UTC" as the timezone into the Release file, where the repository format references policy 4.4 but states that it has to be always in UTC. The example given hence states "+" as the timezone, which is the only timezone specification allowed in the trailer of changelog entries. apt pipes it through a function that allows more timezones (RFC1123StrToTime), specifically GMT/UTC/Z are hardcoded in it. Is there a particular reason why we need to allow this if + denotes the same value? Could we at least document the field properly? ;-) I'll also note that policy is slightly ambiguous on how the date is supposed to be specified: "dd is a one- or two-digit day of the month (01-31)" -- This reads to me as if zero padding is required according to the example but not according to the text. Kind regards and thanks Philipp Kern
Bug#619990: developers-reference: Update of merkel.d.o URLs
On Tue, Mar 29, 2011 at 09:09:55AM +0200, Raphael Hertzog wrote: > But I think it's not very important: > - the former is web accessible at > http://ftp-master.debian.org/testing/update_output/ > - the latter is probably not really the reference implementation of britney > anymore > it can either be removed or replaced with > http://git.debian.org/?p=debian-release/britney1.git;a=summary and > http://git.debian.org/?p=debian-release/britney2.git;a=summary True. I've still set up a sync between franck and ries now. It should be synced every two hours and after britney. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [buildd-tools-devel] re buildd's resolver and package's build deps
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote: > From discussion on IRC earlier this evening, it looks like the most > pragmatic approach will be to get the apt and aptitude sbuild > resolvers to strip the alternatives (after arch reduction), which > will make them behave pretty much exactly like the old internal > resolver, but without its bugs. This will leave maintainers free to > use alternative dependencies, but like now they will be ignored. > What we can do though, is make the use of alternatives configurable > in sbuild, so you will be able to make use of them when building for > other suites e.g. backports. This will disable the stripping. I find this acceptable[0]. Thanks for driving this. Kind regards Philipp Kern [0] I didn't agree with the earlier suggestion of telling people to stop the use of alternatives instead of using predictable behaviour on the resolver side but tried to stay out of the thread. signature.asc Description: Digital signature
Bug#299007: Insecure PATH in /root/.profile
block 611501 by 299007 severity 611501 wishlist # It's not really security-related, as it's currently the defined and # expected behaviour, albeit some people want to change this. tag 611501 - security thanks Russ, On Sun, Jan 30, 2011 at 11:46:23AM -0800, Russ Allbery wrote: > Philipp Kern writes: > > The tech-ctte did decide on that matter. What's the progress on this > > bug now? Is there any action taken as a consequence of it? > It's waiting for someone to do the work required to come up with a > transition plan. No one so far has had time and interest to work on it. > The details of what needs to be done at a high level are covered in the > open Policy bug. ok, marking a bug I received as such. Thanks Philipp Kern signature.asc Description: Digital signature
Bug#299007: Insecure PATH in /root/.profile
Russ, On Fri, Jun 06, 2008 at 12:11:47PM -0700, Russ Allbery wrote: > This proposal asks that directories in /usr/local no longer be writable by > group staff. > > There clearly was not consensus in this bug discussion for making this > change, but neither am I comfortable as a Policy delegate with simply > closing it, in part because those in favor of this change felt very > strongly about it and in part because Ubuntu has made a different decision > and implemented this change. Debian need not follow Ubuntu, but where > Ubuntu has decided to diverge, we should look at their rationale and > consider it seriously. > > I'm therefore going to delegate this decision to the tech-ctte under > points 1 and 3 of section 6.1 of the Debian Constitution. I'm filing the > bug against tech-ctte now. The tech-ctte did decide on that matter. What's the progress on this bug now? Is there any action taken as a consequence of it? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Source architecture field?
On Thu, Nov 25, 2010 at 07:45:16PM +0100, Luk Claes wrote: > On 11/25/2010 07:18 PM, Guillem Jover wrote: > > On Thu, 2010-11-25 at 16:25:35 +0200, Peter Pentchev wrote: > >> In #509702, Philipp Kern says that a particular package's list of > >> architectures should be specified in the source stanza of the control > >> file, not in the binary packages' descriptions, to avoid any attempt > >> to build the package on the rest of the architectures. > > buildd should be looking at the Architecture field in the .dsc file, > > not the debian/control file, AFAIK. > >> While this sounds as a very sensible idea, is this actually allowed and > >> used? From the wording of Policy 5.2 it seems that the Architecture > >> field is only allowed in the binary package paragraphs, and not in > >> the Source one. However, since I seem to remember some connection > >> between Philipp Kern and the Debian autobuilders, I'm inclined to > >> believe that he knows what he's talking about ;) and the autobuilders > >> will actually honor a list of architectures in the source stanza. > >> (A side point is that Policy 5.2 does not list other fields that it is > >> possible to put in the Source stanza, like Vcs-*, but that's another > >> kettle of beer) > >> So... should Policy 5.2 also list Architecture in the source stanza, > >> or should #509702 be closed with "unfortunately this is not allowed"? :) > >> (of course, the former option would be preferable if it actually works :) > > It's really not allowed, and dpkg-dev will just not honour it anyway, > > so the bug report seems confused. I've CCed Philipp, as maybe the > > report was about something else, and he wrote something different from > > what he meant? > Note that the .dsc file is part of the source package, so you probably > misinterpreted what he said? I don't know the context of your question > is, though it seems to me that you should specify in the control file in > the architecture fieled of the binary stanza(s) on which architectures > it should get built and not mention any architecture in a description field. Yeah, what I really meant is basically having it in the .dsc and thus in the source stanza as found in Sources. In this case this doesn't work because fenix-dev is arch:all. If it wouldn't be then dpkg would propagate the binary architecture list into the .dsc and the buildds would skip it. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Automatic Debug Packages
On 2009-08-13, Manoj Srivastava wrote: >> Ah, and it looks like the automated crash reporting offers to download the >> -dbgsym packages and install them. > Reading the spec, it seems to me that the primary motivation was > for users to provide crash dumps with bug reports, and not much screen > time is given to users debugging their own applications linked to > vendor libraries, or for the developer user in general. I think that > use case should be addressed as well. This use case is IMHO implicitly addressed by making them downloadable and installable on the local system. And I have to agree with Emilio that I don't see the point of a 1:1 relationship of ddeb to binary package just for the sake of library transitions. I wonder if we could just unpack the debugging build-id objects to some other location than globally and point gdb to that in addition to the global debug store. Someone should've pointed a summary of how Ubuntu does it, it seems. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
["Followup-To:" header set to gmane.linux.debian.devel.general.] On 2009-08-11, Russ Allbery wrote: >> If it's legal to ship debugging symbols for them, I can't see why we >> couldn't support them normally. > The point is that you can't do this with an archive area, at least using > the simple algorithm I proposed above. Well you can. I always thought concrete sections etc. are an implementation detail that has nothing to do with policy, but ok. Volatile uses volatile/main/ (which is a pain yet to be solved by moving to ftp-master), but you could as well do debug//. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-10, Roger Leigh wrote: > That's what I meant (just not sure of the correct dak terminology). > Would this present problems for the ftp-masters, since TTBOMK currently > source and binary packages are restricted to the same area? i.e. would > work on projectb/dak be required to implement such functionality? IMHO you can build single binaries that live e.g. in contrib from a package in main so this should be a non-issue. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-10, Manoj Srivastava wrote: >> Most -dbg packages *shouldn't* live in the archive, but maintainers >> keep adding them by hand anyway, and we don't have anywhere else to >> put them. > Well, right now there is nowhere to put the .ddebs either, and > they are really just .debs with a funny name too. Not very different. I agree that we do not really need the .ddeb extension as we need to avoid clashes in the package namespace anyway, with the extension not helping us with that. >> I'm not sure we would ever want to take packages that are >> referenced in the source debian/control and move them to the separate >> debug archive, I think that would play havoc with database >> consistency. It also gives us no clear way to tag files referenced in >> a .changes file as belonging to the debug archive *except* for the >> package name, and there are certainly -dbg packages that intentionally >> contain things other than detached debugging symbols and which should >> not be grouped with the ddebs. > How is a .ddeb package going to change things by the time it > gets into the archive? .ddebs will be there in the .changes file, and > the only way they are different is in the file name. I'd guess we could also invent another section or priority for it if we want to. (But we didn't rely on such provided data yet, the authoriative data always comes from the override database.) >> The other end is that we need a usable hook for detaching the symbols >> instead of discarding them, which is trivial for all debhelper-using >> packages, and not at all trivial for packages not using debhelper. > > Why is it not trivial? I have such a hook in my pakages, and it > is not rocket science. > > If you think that adding stuff like > --8<---cut here---start->8--- > filelib_or_exec_file > objcopy --only-keep-debug lib_or_exec_file debug_file > objcopy add-gnu-debuglink debug_file lib_or_exec_file > > strip --remove-section=.comment --remove-section=.note \ > --strip-unneeded lib_file > strip --remove-section=.comment --remove-section=.note exec_file > --8<---cut here---end--->8--- > > to a rules file is "not at all trivial", then heaven help us. Plus lines to actually create the package with appropriate control info or/and putting it into debian/control which we wanted to avoid (I think). Of course if we then go and try to modify the behaviour slightly (like having build-ids and stuff) we still have to modify all those packages and not just the helper and a binNMU. But I guess I can't argue with you about that anyway. From a policy PoV you're right, we do not impose debhelper upon everyone. I already consider debhelper coverage as a worthy goal. :-P Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On 2009-08-10, Manoj Srivastava wrote: >> dpkg "knows" about them the same way it "knows" about debs, AFAICS. > Why, then, the .ddeb suffix? Why are these not just .debs, with > a specific naming schema? At least they shouldn't clash with maintainer-defined ones, IMHO, as they are created differently. The main point is probably that they shouldn't live in the main archive due to space reasons. Of course we could also filter out '*-ddeb*' or '*-dbgsym*' as long as it's not '*-dbg*', which should be dropped at some point but should live in the main archive if present as they're defined in debian/control. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
