Re: [RFC] General Resolution to deploy tag2upload

2024-06-17 Thread Jessica Clarke
On 17 Jun 2024, at 14:53, Ansgar   wrote:
> 
> Hi,
> 
> On Mon, 2024-06-17 at 08:30 +0200, Matthias Urlichs wrote:
>> On 17.06.24 00:04, Joerg Jaspert wrote:
>>> Still, we should find a way to keep the existing property of verifying
>>> what the uploader signed to upload *without* requiring a third-party
>>> $something to be available.
>> 
>> Verifying what the uploader signed is simple enough, it's a git tag. You 
>> fetch it and verify that the hashes match ("git fsck"; current git is
>> hardened against SHAttered) and that it's signed by the correct key.
> 
> That's not usable though to match to what dak gets.
> 
>> You want to verify t2u's work? Simple enough, run dgit and compare to
>> whatever t2u sent you. No $something required.
> 
> No, I just want it not to duplicate authentication and authorization in
> incompatible ways. Sadly tag2upload developers explicitly do not want
> that.
> 
>> Oh wait, t2u isn't even "third party". It's a Debian tool running on 
>> properly-administered (we assume) Debian hardware, running just another 
>> build step in a sandbox.
> 
> It's a third party that would accept uploads that dak would reject for
> security and/or policy reasons (including security critical ones); that
> is not easily fixable if tag2upload is deployed as is (and the
> developers have indicated that they do not want to change that).
> 
> It essentially introduces an alternative authentication system (and
> authorization system as tag2upload seems to care about DM status) that
> *replaces* the one in dak *and* *disagrees* it. Even when you fix one
> of the instances where the systems disagree, the basic problem remains
> (~> at least technical debt). It is very bad design to have multiple of
> these for a single system as you significantly increase the attack
> surface (and one of these usually ends up with less maintenance than
> the other). (Only one of the systems has to allow the upload, i.e., a
> big "*OR*".)

Would an API for tag2upload to use satisfy that concern? It feeds in a
source package name and key fingerprint (or the signature, or
whatever’s deemed useful), dak replies whether it’s valid for
uploading. Then you don’t need to trust tag2upload’s authorisation
checks beyond that it adheres to what dak says each time.

Jess



Re: "gr_rms" rejected but "Debian Project Leader 2021 Election" worked

2021-04-15 Thread Jessica Clarke
On 16 Apr 2021, at 00:59, Osamu Aoki  wrote:
> 
> Hi again,
> 
> This is not GMAIL problem.  This involves only My PC and Debian
> servers.
> 
> (I use gmail only for recieving mails.  I send mail from my Debian
> shell account using SSH when I use @debuian.org address to avoid mail
> rejections.  So Gmail has nothing to do with my problem.)
> 
> $ date -u --iso=sec
> 2021-04-15T23:44:44+00:00
> 
> So still in voting period as far as I am concerned.
> 
> I think the problem is:
>>>   gpg: WARNING: unsafe permissions on homedir
>>>   '/srv/vote.debian.org/data/gr_rms'
> 
> I think times execution of permission setting to close voting may have
> kicked in too early.

No, that’s just a warning, it happens on every ballot, though you only see it
if there’s also another error. You’re likely running into the same problem I
did, which is that the RMS ballot has lines long enough to be wrapped under
quoted printable, whereas the DPL election fits within the line limit. Are you
using an inline signature rather than a detached signature? The former is not
robust against MTA wrapping, but the latter is, and is what’s recommended.

Jess



Re: General Resolution: please vote responsibly

2021-04-04 Thread Jessica Clarke
On 4 Apr 2021, at 12:38, Pasha  wrote:
> On Sun, 2021-04-04 at 12:31 +0100, Jessica Clarke wrote:
>> On 4 Apr 2021, at 12:27, Dmitry Smirnov  wrote:
>>> 
>>> I urge everybody to vote responsibly and thoughtfully.
>>> 
>>> Cancel mob can never be satisfied and, if encouraged, they will
>>> demand
>>> more sacrifices soon.
>> 
>> The discussion period is over. Everyone should indeed vote
>> responsibly and
>> thoughtfully, which, being a democratic process, means they should
>> vote for
>> what *they* believe in, not what you or anyone else thinks.
>> 
>> Jess
>> 
> 
> FSF board also followed some process but some people are trying to
> remove entire board now.
> 
> If some other organiztions who use tools from Debian - demand similar
> things for Debian DDs who voted against them !

I said the discussion period is over. Leave the developers to democratically
express their views.

Jess



Re: Debian Project Leader election 2021: both candidates are from cancel mob

2021-04-04 Thread Jessica Clarke
On 4 Apr 2021, at 12:33, Dmitry Smirnov  wrote:
> 
> On Sunday, 4 April 2021 9:49:57 AM AEST Debian Project Secretary - Kurt 
> Roeckx wrote:
>> [ ] Choice 1: Jonathan Carter
>> [ ] Choice 2: Sruthi Chandran
> 
> FYI, both cancel mob candidates signed anti-RMS statement:
> 
>  
> https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md

The discussion period is over. If you don’t like either of the candidates, cast
your vote for "Choice 3: None Of The Above". Stop trying to force your own
views onto people like you just did for the GR.

Jess



Re: General Resolution: please vote responsibly

2021-04-04 Thread Jessica Clarke
On 4 Apr 2021, at 12:27, Dmitry Smirnov  wrote:
> 
> On Sunday, 4 April 2021 9:50:01 AM AEST Debian Project Secretary - Kurt 
> Roeckx wrote:
>> This is the first call for votes on the General Resolution about
>> a statement regarding Richard Stallman's readmission to the FSF board.
> 
> I urge everybody to vote responsibly and thoughtfully.
> 
> Cancel mob can never be satisfied and, if encouraged, they will demand
> more sacrifices soon.

The discussion period is over. Everyone should indeed vote responsibly and
thoughtfully, which, being a democratic process, means they should vote for
what *they* believe in, not what you or anyone else thinks.

Jess



Re: Amendment to RMS/FSF GR: Option 5

2021-04-02 Thread Jessica Clarke
On 2 Apr 2021, at 14:49, Zlatan Todoric  wrote:
> On 4/2/21 09:20, Craig Sanders wrote:
>> TEXT OF OPTION 5
>> 
>> 
>> Debian refuses to participate in and denounces the witch-hunt against Richard
>> Stallman, the Free Software Foundation, and the members of the board of the
>> Free Software Foundation.
>> 
>> 
>> 
>> 
> I sincerely think debian-vote should be read-only for non-DDs

Agreed.

> because this person is not a DD (afaict) and is just polluting our list with 
> such non-sense.

https://nm.debian.org/person/cas/

Jess



Re: Announcing new decision making procedures for Debian

2021-03-31 Thread Jessica Clarke
On 1 Apr 2021, at 00:06, Alejandro Nadal  wrote:
> 
> How will "the strength of the wording" be measured? I am not a DD, just a 
> debian user, curious about the new process.

Swearing and personal attacks are great ways to demonstrate your passion.
Comparisons to communism, genocides and nazis are all particularly strong.

> Also, doesn't this give more influence to those developers with more time to 
> write more mails, if the number of messages will be taken into account?

Yes; if you can’t find time to write the emails then you clearly care less than
those who do make the time.

> (If this message breaks the mailing list protocol in any way, I am deeply 
> sorry, I am new to these debian mailing lists)

Top-posting is awful and should be an instant rejection of any opinions for a
GR IMO, same as non-plaintext replies and not line-wrapping.

Jess

> Alejandro Nadal
> 
> On Wed, Mar 31, 2021, 19:53 Enrico Zini  wrote:
> Hello Debian Members,
> 
> For some time, we have been having systemic issues that make GR
> discussions painful. GRs themselves shouldn't be painful, and don't need
> to be. Having a chilling effect to using GRs hurts Debian, and as a
> project we need a way to poll for consensus on project choices and
> directions more often than not.
> 
> To overcome the current problems with GR discussions, we introduce a
> replacement weighted democratic system. The new procedure is this:
> 
>  * A developer proposes an issue with a signed message on
>debian-vote@lists.debian.org .
> 
>  * Anyone can express their consent or dissent by replying to the
>message.
> 
>  * When the discussion eventually dies down, the Debian Secretary will
>review all messages and pronounce the winner.
> 
> 
> This method makes the fair assumption that the energy spent in writing
> messages to the discussion is related to the amount of insight a person
> has on an issue, and how much they care about it. In particular:
> 
>  * The more messages a person writes, the more the person cares, and the
>more their opinion will be taken into account: people who only write
>every once in a while, clearly don't think the issue is important
>enough to deserve their real effort.
> 
>  * The more strongly worded replies are, the more the person cares, and
>the more their opinion will be taken into account: people who waste
>time with long, polite, well reasoned messages, clearly didn't care
>enough to get emotional about an issue.
> 
>  * The longer a person keeps writing, the more the person cares, and the
>more their opinion will be taken into account: people who give up,
>clearly didn't care enough to make themselves heard.
> 
> To avoid confusion, we'll maintain the same acronym as before. The new
> system will be called Debian Grandiose Reflection.
> 
> The first GR using this scheme will concern the introduction of this
> voting scheme for the future.
> 
> 
> Enrico
> 
> -- 
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini