Re: t2u in the archive

Matthias Urlichs writes: > On 01.07.24 12:46, Aigars Mahinovs wrote: >> Yes and no. See what the git tag actually contains and what the GPG >> signature actually signs is just the one hash of the commit object. >> This commit object then refers to the other files of the repo, but the >> GPG

Re: Security review of tag2upload

Brian May writes: > Simon Josefsson writes: > >> Successfully attacking ALL individual developers, with each own >> individual security weaknesses, seems to me more costly than attacking a >> single known publicly run instance like tag2upload or Salsa. >

Re: Security review of tag2upload

Russ Allbery writes: > Scott Kitterman writes: > >> I agree that there's a risk that what the uploader thought they were >> uploading and what they actually uploaded are different, but that's >> independent of tag2upload or not. > > But it's not independent; tag2upload makes this story somewhat

Re: How is the original tarball obtained in tag2upload

Phil Morrell writes: > On Fri, Jun 14, 2024 at 12:26:50PM +0100, Ian Jackson wrote: >> Andreas Tille writes ("How is the original tarball obtained in tag2upload"): >> > In many teams we keep the metadata about the >> > orig.tar.$COMPRESSION tarball in pristine-tar branch. In most cases >> >

Re: [RFC] General Resolution to deploy tag2upload

Russ Allbery writes: > Simon Josefsson writes: >> Ian Jackson writes: > >>> No. The git commitid of the upstream source is named in the tag >>> generated by git-debpush. (So that upstream git branch has to be in >>> your git repo somewhere - ju

Re: [RFC] General Resolution to deploy tag2upload

Ian Jackson writes: > Ansgar  writes ("Re: [RFC] General Resolution to deploy tag2upload"): >> On Thu, 2024-06-13 at 05:58 +0800, Sean Whitton wrote: >> >   tag2upload already supports most existing workflows (including the one >> >   you yourself prefer, where only debian/ is committed to

Archive support for *.orig.bundle.* and *.debian.bundle.*

Simon Richter writes: > One _incremental_ change I'd like to see would be archive support for > .orig.bundle.* (containing a shallow copy of the upstream commit) and > .debian.bundle.* (containing the differences between the upstream > commit and the package), which would be an absolute game

Re: Security review of tag2upload [transfer.fsckObjects]

Russ Allbery writes: >> Can this be substantiated? Using SHA1CD in Git does not necessarily >> mean someone cannot manually create a Git repository with a colliding >> git commit somewhere in the history that gets accepted by git, and >> allows someone to replace actual file contents. That may

Re: Security review of tag2upload

Simon Richter writes: > Hi, > > On 6/13/24 22:27, Simon Josefsson wrote: > >> Generally I reach the same conclusion, although I think there are real >> security problems with both the existing and the proposed tag2upload >> mechanism that we should all be aware of

Re: Security review of tag2upload

Russ Allbery writes: > The decision on whether to adopt tag2upload should be made primarily on > non-security grounds. Generally I reach the same conclusion, although I think there are real security problems with both the existing and the proposed tag2upload mechanism that we should all be

Re: Possible draft non-free firmware option with SC change

Lucas Nussbaum writes: > On 13/09/22 at 14:49 +0200, Simon Josefsson wrote: >> Lucas Nussbaum writes: >> >> > Right. I think that it's important to realize that the FSF and Debian >> > use different tactics to promote Free Software. The FSF focuses o

Re: Possible draft non-free firmware option with SC change

Lucas Nussbaum writes: > Right. I think that it's important to realize that the FSF and Debian > use different tactics to promote Free Software. The FSF focuses on > promoting a clean ideology to the point of ignoring practical problems. > The risk is becoming irrelevant, because very few people

Re: Possible draft non-free firmware option with SC change

Tobias Frost writes: > On Tue, Sep 13, 2022 at 07:29:05AM +0200, Simon Josefsson wrote: > >> My reason for using Debian is that I can rely on getting a 100% free >> system, and then add non-free works on top of it when I chose to do so. >> >> For example,

Re: Possible draft non-free firmware option with SC change

Ansgar writes: > Hi, > > On Mon, 2022-09-12 at 21:03 +0200, Simon Josefsson wrote: >> My experience is the same as you describe, with the free installer: >> if you pick the right hardware, Debian works directly today. > > By "right hardware", I assume you

Re: Possible draft non-free firmware option with SC change

Thanks for long post, thoughtful and I only have a reflection left: >> Okay. But given a situation when someone comes to you with a hardware >> component that requires non-free software to work, and asks you to >> install Debian on it, would you resolve that by > >>1) install the free Debian

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Simon Josefsson writes: > >> I recall that it took ~5 years until hardware (usually audio, video, >> network cards) was well supported with stable releases of free software >> distributions in the 1990's. Often it was never possible to get

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Simon Josefsson writes: > >> Thanks -- this helps me understand the two principles at play here: > >> 1) having a free Debian > >> 2) having a Debian that works on as much hardware as possible > > This summary is moving in the righ

Re: Possible draft non-free firmware option with SC change

Steve McIntyre writes: > Many common laptops in the last 5-10 years don't come with wired > ethernet; it's becoming rarer over time. They ~all need firmware > loading to get onto the network with wifi. Many now need firmware for > working non-basic video, and audio also needs firmware on some of

Re: Possible draft non-free firmware option with SC change

Steve McIntyre writes: >>I think the difference of opinion is that your proposal is based on the >>argument that it is worth compromising on the ideals of free software in >>order to allow users to be able to run free software. I disagree with >>that opinion. If you disagree with my

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > I think it is possible to argue in good faith that the Debian installer is > not part of the Debian system as defined in SC 1. I would not personally > make that argument, but I don't think it's an unreasonable argument to say > that the Debian system is the packages in

Summarizing options

: > On Sun, 2022-09-11 at 10:28 +0200, Simon Josefsson wrote: > >> * Would it prevent the current presentation of the non-free installer? >> tl;dr: No >> * Would it prevent the alternative presentation suggested in >> https://lists.debian.org/msgid-search/683a7c0e69b08

Re: Changing how we handle non-free firmware

I was asked offlist to answer how Proposal D would affect the display of the non-free installer on Debian websites, and in particular: * Would it prevent the current presentation of the non-free installer? tl;dr: No * Would it prevent the alternative presentation suggested in

Re: Possible draft non-free firmware option with SC change

Paul Wise writes: > On Sat, 2022-09-10 at 09:16 +0200, Simon Josefsson wrote: > >> So the practical problems facing people requiring non-free software >> appears solved or possible to solve. > > As I understand it there are two problems solved by proposal A/E: &g

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Simon Josefsson writes: > >> No, not like now. Today we and our users can chose to download non-free >> content if they want. Some do. Some don't. With Steve's proposal, as >> I understand it, that choice will be taken away. > > S

Re: Possible draft non-free firmware option with SC change

Andrey Rahmatullin writes: > On Fri, Sep 09, 2022 at 09:16:48AM +0200, Simon Josefsson wrote: >> With your proposal, Debian 'main' would still consists of free content, >> but to practically install and run any of it, we and our users would >> have to download non-free co

Re: Changing how we handle non-free firmware

Bart Martens writes: > Yes, let's do that, thanks. So here is the adapted proposal C: > > = > > The Debian project is permitted to make distribution media (installer images > and live images) containing non-free software from the Debian archive > available > for

Re: Possible draft non-free firmware option with SC change

Steve McIntyre writes: > On Thu, Sep 08, 2022 at 05:22:58PM +0200, Simon Josefsson wrote: >>Simon Richter writes: >> >>> The reason I'm in favor of changing the SC is not that I believe it to >>> be a good thing, but that I think we need to stay relevant fo

Re: Possible draft non-free firmware option with SC change

Simon Richter writes: > The reason I'm in favor of changing the SC is not that I believe it to > be a good thing, but that I think we need to stay relevant for running > on actual hardware, and changing the SC now is the only way to do so > given that the actual hardware is non-free. What has

Re: Changing how we handle non-free firmware

Kurt Roeckx writes: > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: >> As far as I can tell, both Steve's and Gunnar's proposal would make >> Debian less of a free software operating system than it is today. That >> makes me sad. My preference for an o

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Possible wording, which includes the existing option A verbatim: Thanks, I prefer this approach over Steve's initial proposal: it solves the problem that we would override a foundational document with a GR without the required 3:1 majority. I'm worried that if we publish

Re: Changing how we handle non-free firmware

Steve McIntyre writes: > Hi Simon! > > On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote: >> >>== >> >>We continue to stand by the spirit of the Debian Social Contract §1 >>which says: >> >> Debian will remain

Re: Changing how we handle non-free firmware

Vincent Bernat writes: > On 2022-08-23 10:39, Simon Josefsson wrote: > >> Therefor we will not include any non-free software in Debian, nor in the >> main archive or installer/live/cloud or other official images, and will >> not enable anything from non-fr

Re: Changing how we handle non-free firmware

Jonas Smedegaard writes: > I view the official Debian install image as a component of Debian, and > consequently if the (only) official Debian install image were to contain > non-free bits then we would violate DSC#1. I also find this problematic. As far as I can tell, the alternatives on this

Re: Changing how we handle non-free firmware

Kurt Roeckx writes: > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: >> As far as I can tell, both Steve's and Gunnar's proposal would make >> Debian less of a free software operating system than it is today. That >> makes me sad. My preference for an o

Re: Changing how we handle non-free firmware

Gunnar Wolf writes: > Simon Josefsson dijo [Tue, Aug 23, 2022 at 07:57:36PM +0200]: >> > I find that if I assume the DSC points are unordered, and numbered only >> > for reference, then there's sentences in there that support the offering >> > of official images

Re: Changing how we handle non-free firmware

Phil Morrell writes: > Just be aware that this rationale can have the opposite of its intended > effect in the long term: > > https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/ My reading of that is that the FSF RYF program does not meet the

Re: Changing how we handle non-free firmware

"Andrew M.A. Cater" writes: > On Tue, Aug 23, 2022 at 10:53:46AM +0200, Simon Josefsson wrote: >> "Andrew M.A. Cater" writes: >> >> > In practice, the free installer is useless on its own. >> >> That is not my experience -- I'm usin

Re: Changing how we handle non-free firmware

Antonio Terceiro writes: > On Tue, Aug 23, 2022 at 10:53:46AM +0200, Simon Josefsson wrote: >> "Andrew M.A. Cater" writes: >> >> > In practice, the free installer is useless on its own. >> >> That is not my experience -- I'm using Debian t

Re: Changing how we handle non-free firmware

"Andrew M.A. Cater" writes: > In practice, the free installer is useless on its own. That is not my experience -- I'm using Debian through its installer on a number of laptops, desktops and servers, and for my purposes it works fine and in general I have not needed to enable non-free/contrib

Re: Changing how we handle non-free firmware

As far as I can tell, both Steve's and Gunnar's proposal would make Debian less of a free software operating system than it is today. That makes me sad. My preference for an outcome would be along the following lines. == We continue to stand by the spirit of the Debian Social

Re: Changing how we handle non-free firmware

Tobias Frost writes: > On Mon, Aug 22, 2022 at 07:39:21AM +0200, Simon Josefsson wrote: >> Ansgar writes: >> >> > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: >> >> Do we need to update the Debian Social Contract for that? >> >>

Re: Changing how we handle non-free firmware

Ansgar writes: > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: >> Do we need to update the Debian Social Contract for that? >> Specifically paragraph 1, which currently reads >> >> Debian will remain 100% free > > No. Just like we don't need to update the Debian Social Contract

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

Kurt Roeckx writes: > The solution to this problem is moving the majority check later > in the process, so that option B would have been dropped first. > If they did this stratigic voting in that case both options would > have been dropped. Interesting -- one thought: haven't