Re: should debian comment about the recent 'ransomware' malware.
Henrique de Moraes Holschuh writes: > On Wed, 17 May 2017, Holger Levsen wrote: >> On Wed, May 17, 2017 at 01:59:37PM +1000, Russell Stuart wrote: >> > Microsoft users or indeed Android users, iOS users and I presume OSX >> > users get security updates installed automagically by default. >> >> that's awesome and I hope by 2019 the default stable Debian desktop install >> will do that too! > > You know, if the stuff we have in testing _rignt now_ works flawlessly, > we can (and should) add to the Release Notes in big red letters that > people ought to install it. It can even be made a post to > debian-announce and debian-security-announce (if the security team > agrees with the notion). >From my experience the current update system doesn't work flawlessly. It is error-prone to upgrade running applications and switch out parts of them while they run: many programs don't like when data files or plugins they rely on suddenly disappear. I've observed this with quite a few applications (such as Firefox, Libreoffice, zsh, emacs, ...). The breakage can result in crashes or just some features suddenly no longer working until restart. Installing updates on system startup seems less risky to me, though some people seem to dislike it for some philosophical reason. Ansgar
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
Hi, Jonathan Dowland j...@debian.org writes: On Mon, Oct 13, 2014 at 06:33:49PM +0200, Matthias Klumpp wrote: You do understand that we have procedured at Debian to handle stuff like GR proposals, right? And that procedure involves posting to debian-vote, so doing that was the right thing to do. Whilst researching for a reply to a different post in this thread on -user (the thread sadly spans at least three lists), I realised that the constitution doesn't say where GRs should be announced, and I couldn't find any advice on the subject in a scan over policy, either. I think we should clearly indicate where GRs should be announced. (Should, I suppose I'm arguing, not must). It's documented on vote.debian.org[1]. [1] https://www.debian.org/vote/howto_proposal Unless I'm mistaken, a change to Constitution (to include a reference to where GRs should be posted) would need to be achieved via GR. Alternatively, we could document it as a should in policy, although there may not yet be an appropriate section to do so. Does anyone have strong feelings on this? I think both would be the wrong place: having technical details (such as mailing list names) in the Constitution makes it hard to change them. And Policy documents packaging standards for the distribution, not procedural details for the project. Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbnnn7hk@deep-thought.43-1.org
Cooperation with the FSF?
Hi, elsewhere I heard that there was some talk (also including people from the FSF) about cooperation with the FSF. Could anybody tell a bit more what current ideas are? I just remember the fsf-collab-discuss list on Alioth with sadly died rather quickly... Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mwaeqzs9@tsukuyomi.43-1.org
Re: Reflecting on users and security updates
On 05/09/2014 16:15, Stuart Prescott wrote: == sources.list Many users of stable releases don't have security.debian.org in the sources.list. I can only wildly speculate as to how this happens... if the installer doesn't find a network connection at install time it leaves a pretty weird looking sources.list and we know lots of people manage to not fix properly. The sources.list that the installer leaves in this case is certainly sub-optimal. What do they end with in sources.list? It would probably be nice if there were entries like # deb http://http.debian.org/debian wheezy main # deb http://security.debian.org/debian-security wheezy/updates main (with comments) in case no network mirror is added by the installer. Maybe with a comment asking to enable *both* if network is accessible. Why do we have a separate archive for security at all? Separate teams and hysterical raisins are possible reasons. Not waiting for a mirror pulse to push out updates is another. Is there any technical reason right now to not copy security updates into the stable release at the next dinstall run rather than waiting a few months for a point release? What would be required to merge these and simplify life for our users? Some reasons are: The stable suite is signed with an offline signing key. It cannot be easily changed. Security updates should be delivered via fast and (more) secure mirrors. If someone grabs a security update for, say, ssh it is likely he is vulnerable. Delivering security updates via a trusted mirror network reduces that risk. The security archive contains updates covered by embargoes that should not be leaked. Log files and database replica for the main archive are more or less public. (Arguably one could have a private archive for just embargoed issues and push to the main archive to release them.) Having two archives makes it possible to release updates should one break. ;) And of course all the historic reasons. Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ce9c6.3000...@debian.org
Upstart trademark policy (was: Re: Proposed MBF - mentions of the word Ubuntu)
Hi, Sune Vuorela nos...@vuorela.dk writes: Is upstart a canonical trademark? some pieces of software in the archive with canonical trademarks in their names? SHould we consider renaming them? According to the footer on their homepage[1], Upstart is a trademark of Canonical Ltd., but I could not find a usage policy for it. Canonical's trademark policy[2] doesn't mention Upstart specifically and is mostly concerned about the Ubuntu mark. For this it makes sense to require modified versions to not be called Ubuntu, but the situation is a bit different with Upstart as Debian might need to patch it (for example due to the CLA[3], differences between Debian and Ubuntu or just backporting bug fixes). Are those modified versions still allowed to be called Upstart? Would Debian and Debian-derived distributions (besides Canonical's Ubuntu) need a trademark license? Or would Debian need to rename Upstart (like Iceweasel)? Ansgar [1] http://upstart.ubuntu.com/ [2] http://www.ubuntu.com/intellectual-property-policy [3] https://wiki.debian.org/Debate/initsystem/upstart#Cons -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y54wsiqv.fsf...@deep-thought.43-1.org
Re: Debian Maintainers Keyring changes
On 09/08/2013 08:58, Kurt Roeckx wrote: On Sun, Sep 08, 2013 at 02:01:43AM +, Debian FTP Masters wrote: The following changes to the debian-maintainers keyring have just been activated: sas...@girrulat.de Removed key: A33FC3A59C40F1BCC3368E88FCA5101964F970D1 Removed key: E67DF5E7FCFAB7218C6D0FAF610711E66630FEFA Removed key: DA813270E09F448D18771FBE1AB9332D9E47CF19 Added key: B7018D75BBAD63F52395B82C5E55B31A2FEDAC22 Added key: FD9F764B0B28B823E02E62EF7809DD1F83DCC74A This looks really confusing. It's DA813270E09F448D18771FBE1AB9332D9E47CF19 that gets removed, the other 2 mentioned are subkeys. And it's FD9F764B0B28B823E02E62EF7809DD1F83DCC74A that gets added with B7018D75BBAD63F52395B82C5E55B31A2FEDAC22 as subkey. Can we change the output so that it's more clear that it's about the pub or the sub key? We should be able to ignore the subkeys. The code should by now only look at the primary key fingerprint (as we don't care which subkey people use as long as it's valid). Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522db9fc.3070...@debian.org
Re: Can we change our position on CC BY 2.0 and 2.5 ?
On 01/25/2013 10:41, Charles Plessy wrote: Le Fri, Jan 25, 2013 at 10:16:24AM +0100, Joerg Jaspert a écrit : On 13102 March 1977, Christoph Egger wrote: Alternatively, if we can not find a significant difference of freedom between CC BY 2.5, and CC BY 2.0, how about accepting CC BY 2.0 in Debian ? We don't want 2.5 in main, we want 3.0. So why? Sorry, I was mislead by the presence of 2.5 in awstats and grub2-splashimages... I filed bugs[1][2] for these two packages. The icons in awstats are even already licensed as CC-BY-SA-3.0[3]. Ansgar [1] http://bugs.debian.org/698921 [2] http://bugs.debian.org/698922 [3] http://famfamfam.com/lab/icons/silk/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5102784b.1010...@debian.org
Re: Planned changes to Debian Maintainer uploads
Hi, Gunnar Wolf gw...@gwolf.org writes: Hmm, this looks interesting, and useful. I'd like to add a bit as a wishlist item: Having this DB easily queriable (i.e. a webpage where you can query by key to see all the packages uploadable by a given key). I agree that the information should be easily available. We can export it to a static HTML page (with optional JS to sort by package or maintainer) and to deb822 format. In addition it will be available in the DD-accessible projectb copy on ries.d.o. And just thinking about possible complications: I *hope* we don't see any such behaviour, but this format would allow a DD to censor a given DM's activity. If I send Deny actions with somebody's key, it ends up blocking that person until somebody else is convinced to send corresponding Allow commands. Of course, if we see any such behaviour (repeatedly?), I might be reprehended and maybe even locked out of sending requests to this subsystem. Thoughts on this? As Arno said this is already a potential problem with the current interface, though I am not aware of any abuse. Blocking access to the command interface would be an option, but I hope we don't need it and would not implement it right away. Finally, it's interesting to me (as keyring-maint) that you are specifying the fingerprint. Of course, it makes sense. But it can make key migration (i.e. a DM moving from a 1024D to a 4096R key, or reacting to a key being compromised) as a more difficult thing, as the new key would first have to be inserted by us into the live keyring and only then the old key denied and the new one allowed. I guess we could automate this procedure when performing the keyring push... Using fingerprints avoids dak to have perform the name - fpr mapping without any interaction (which would probably have the same problems as we already have for people with multiple uids). Key migration is indeed a small problem as the key needs to be known to dak in order to grant upload permissions. So you can only move permissions after the new keyring is active, but maybe we could add a command to migrate between keys to make this easier. (Should this be restricted to keyring maintainers? Or only available for ftpmaster and keyring maintainers ping us[1]?) Ansgar [1] Which would be easier to implement as dak would not need to know who is a keyring maintainer. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vftwtu8@deep-thought.43-1.org
Re: Planned changes to Debian Maintainer uploads
Hi, Tollef Fog Heen tfh...@err.no writes: Could we have an expiration date associated with the grants? I might grant somebody rights to a package, but want it to expire within $period (or at least be subject to more aggressive QA/MIA checks than a normal DD), since I'll be tied to them in a way. I agree with zack that we shouldn't require DMs to periodically renew upload permissions for every package. We already require them to reconfirm their interest to stay DM annually. Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871ullwtmn@deep-thought.43-1.org
Re: Planned changes to Debian Maintainer uploads
Hi, Ian Jackson ijack...@chiark.greenend.org.uk writes: Ansgar Burchardt writes (Planned changes to Debian Maintainer uploads): Your proposal simultaneously changes two things: - It applies to all DMs listed as Maintainer/Uploaders. It is not possible to grant upload permission to only a specific DM. This does involve changing the structure of the metadata. And I find it difficult to see what it would mean to list a DM as a Maintainer or an Uploader if they weren't supposed to be able to upload the package. The same as it means for package without DM-Upload-Allowed or for non-D[DM]s: they maintain the package. See also gregoa's mail[1] why we would like to change this. [1] https://lists.debian.org/debian-project/2012/06/msg00046.html - It is tied to the source package so can only be changed with a sourceful upload. This is slightly annoying but given that maintainership changes involve an upload too, it hardly seems fatal. Has this been a problem in practice ? I think this has been answered by Gerfried's[2] and David's[3] mails. [2] https://lists.debian.org/debian-project/2012/06/msg00038.html [3] https://lists.debian.org/debian-project/2012/06/msg00037.html - It allows DMs to grant permissions to other DMs. It is far from clear that forbidding this is the right thing to do. Why? In my understanding upload permissions for a (package, DM) should be granted by a DD once he is convinced that this specific DM is able to look after the given package. DMs were never supposed to grant this to other DMs. The fact that this is possible is an oversight in the initial DM specification. Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr3dvem7@deep-thought.43-1.org
Planned changes to Debian Maintainer uploads
Hi, (Please send followup messages to -project.) The ftp team wants to change how allowing Debian Maintainers to upload packages works. The current approach with the DM-Upload-Allowed field has a few issues we would like to address: - It applies to all DMs listed as Maintainer/Uploaders. It is not possible to grant upload permission to only a specific DM. - It is tied to the source package so can only be changed with a sourceful upload. - It allows DMs to grant permissions to other DMs. We plan to instead implement an interface where developers upload a signed command file to ftp-master to grant upload permissions instead, similar to dcut. This could end up looking similar to this: --8---cut here---start-8--- Archive: ftp.debian.org Action: dm Fingerprint: [...] Allow: a-source another-source Deny: yet-another-source Reason: We want people to say why they changed that. Action: dm Fingerprint: [...] Allow: yet-another-source Reason: ... --8---cut here---end---8--- Here Allow would add additional packages to the list of packages the Debian Maintainer (identified by his key fingerprint) may upload. Deny would be used to revoke this permission again[1]. Any DD may use this to grant/revoke upload permissions to existing packages (ie. at least in NEW); referring to non-existing packages will be an error (at least for Allow). [1] Having the same package in both Allow and Deny at the same time would result in revoking permissions. The Archive field is to prevent forwarding the commands file to another dak installation. Granting upload permissions for backports.d.o will require sending a commands file explicitly to backports-master. We will also drop the check that the DM is in Uploaders of the previous version and Changed-By of the current version. This has caused problems for DMs that have multiple uids attached to their key in the past. (This technically allows DMs to sponsor uploads to packages they have upload permissions for and to grant upload permissions to packages the DM does not maintain (yet). This should not be abused.) Please note that we currently do not know when we might get around to implement these changes. Ansgar for the ftp team pgpkXH2CA49IE.pgp Description: PGP signature
Re: Is there a public-facing page of the various autobuilders ? more specifically hardware specs.
Hi, I think -project@ might be a better list for this. On 02/21/2012 03:14 PM, shirish शिरीष wrote: The info. I'm looking for is the physical infrastructure as to the kinda specs (hardware specs of the machines) on the network are and if they are located at diverse locations (or not). [DB] has a list of machines in use by Debian, you want to look for hosts which have listed buildd purpose. For bandwidth usage, you could try the munin instance maintained by DSA [MUNIN]; access details can be found on [DSA]. [DB] http://db.debian.org/machines.cgi [MUNIN] http://munin.debian.org/ [DSA] http://dsa.debian.org/ I do know that there is a mailing list dedicated for DD,DM's wanna-build [04] but am not sure if my query would be entertained there (as I'm no DD,DM or even a package uploader, just an interested user who uses stuff from Debian). Just try asking them, most people don't bite (or at least not too hard). You might also be interested in [ORG] and [TEAMS] which has a bit more information. [ORG] http://www.debian.org/intro/organization [TEAMS] http://wiki.debian.org/Teams (Have no idea for instance if autobuilders have direct access to the archive [05] and if they don't what kind of bandwidth is needed. I do know that in the past vendors like HP and others have donated machines for autobuilding and things. Hmm, I am not sure if there is much documentation about this, but as far as I know buildds usually have access to the archive (they can use mirrors as well), including packages not yet pushed to the mirror network (similar to [INCOMING] but with signed Packages indices for use with APT). [INCOMING] http://incoming.debian.org Regards, Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f43b12e.3030...@debian.org
Re: Help
Hi, please do not sent support requests to debian-project@, instead use one of the documented channels[1]. The how to ask questions the smart way document[2] may also be helpful if you want others to understand your problem. Regards, Ansgar [1] http://www.debian.org/support [2] http://catb.org/esr/faqs/smart-questions.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipjiobco@deep-thought.43-1.org
