I am not an expert but the encryption discussion is
extremely important. Are you familiar with the Secure Email
Lists (SELS) project? If not, drop everything and look at
it at right now
http://sels.ncsa.illinois.edu/index.html
http://www.ncsa.illinois.edu/People/hkhurana/SAC05_1.pdf
To my lim
ehr...@greenhouse.economics.utah.edu writes:
> I am not an expert but the encryption discussion is
> extremely important.
We are not currently discussing encryption, but rather signing. A
similar approach might work for signing, but it's subject to a weaker
form of the objection below.[1]
>
On Jul 02, 2013, at 01:04 PM, Stephen J. Turnbull wrote:
>No, in Mailman 3 it is not, and cannot be, internal to OpenPGP because
>addresses are *not* Users. There is a many-to-one (address-to-User)
>mapping (I hope; if it's many-to-many, we can probably dodge that
>bullet by allowing sets of User
Daniel Kahn Gillmor writes:
> On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
> > The way I think of it is that Users may have several roles (read,
> > post, moderate, admin) for each list. Each of these roles may be
> > certified by a different "agent" of the owner, where agents are
> >
On 07/01/2013 01:58 AM, Stephen J. Turnbull wrote:
> > 2) subscribers to an OpenPGP-enabled mailman mailing list subscribe,
> > unsubscribe, receive, and send mails as usual (though messages not
> > signed with valid keys will not be re-sent to the list).
>
> Not necessarily. It may be necess
Daniel Kahn Gillmor writes:
> Maybe we're not talking about the same thing. OpenPGP certification
> should be identity certification, and nothing else. trying to extend
> OpenPGP certification to mean something other than identity
> certification sounds like a bad idea to me -- it breaks all
On 06/29/2013 12:49 AM, Stephen J. Turnbull wrote:
> Daniel Kahn Gillmor writes:
> > OpenPGP certifications should attest to people's identities; those
> > identities should have permissions in mailman the same way that
> > non-cryptographically-verifiable identities have permissions in
> > mai
Daniel Kahn Gillmor writes:
> ok, of course you have priority here, but i don't think we're actually
> disagreeing :)
Good!
> The "simple, generic mechanism" you describe *is* key
> manangement as far as i'm concerned, and i think it's an excellent
> step.
OK. I remember the context as be
On 06/28/2013 10:11 AM, Barry Warsaw wrote:
> Another complication is that keys will probably be attached to users, but
> users have relationships with list across the entire Mailman installation. So
> if it were list owners that were responsible for key management, how does that
> cross list bou
On 06/28/2013 12:03 AM, Stephen J. Turnbull wrote:
> Daniel Kahn Gillmor writes:
>
> > I think Abhilash's question above is a really important question,
>
> It is.
>
> > and one that really should be addressed by this GSoC project.
>
> Vetoed (I'm the mentor). Abhilash is welcome to work on
All great questions. Let me just add this.
On Jun 28, 2013, at 01:03 PM, Stephen J. Turnbull wrote:
>There does need to be a way for list owners to take complete control of key
>management, and there does need to be convenience in management. I think
>that the "key signed by list-owner's list-k
Daniel Kahn Gillmor writes:
> I think Abhilash's question above is a really important question,
It is.
> and one that really should be addressed by this GSoC project.
Vetoed (I'm the mentor). Abhilash is welcome to work on key
management if he wants to, but he will not be evaluated on it (su
On Sat 2013-06-15 12:48:34 -0400, Stephen J. Turnbull wrote:
> Abhilash Raj writes:
>
> > * How to ensure the keys belong the email it says it does?
>
> This is not in scope for your project. Key upload is for
> bootstrapping strong authentication, therefore you should assume there
> is no stron
Barry Warsaw writes:
> It's a valid complaint. What I've suggested in the past is that a
> rule can do some *nondestructive* processing of a message before it
> makes its decision. The rule would either throw out the results of
> the processing (possibly leading to duplication of work) or wo
On 06/15/2013 11:42 PM, Stephen J. Turnbull wrote:
>
> Barry Warsaw writes:
>
> > I know this is a little backwards, but it's probably the best match
> > for the current rule/chain model.
>
> I have a smallish problem with this model. Specifically, for a list
> with a maximum size, I think it
On 06/15/2013 02:45 PM, Barry Warsaw wrote:
>
> On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote:
>
>> * Inline pgp should be supported or not?
>
> Probably not as a first step. PGP/MIME will be easier to support so do that
> first. As Stephen suggests, a survey of popular MUAs might be useful
On Jun 16, 2013, at 03:42 PM, Stephen J. Turnbull wrote:
>Barry Warsaw writes:
>
> > I know this is a little backwards, but it's probably the best match
> > for the current rule/chain model.
>
>I have a smallish problem with this model. Specifically, for a list
>with a maximum size, I think it's
Joost van Baal-Ilić writes:
> Indeed, that could work. Another way to deal with it could be: "a
> key is considered valid if it is imported in the trusted keyring of
> the current list". And declare deciding wether to import out of
> the scope of the project.
I think that we necessarily hav
Hi,
On Sun, Jun 16, 2013 at 01:48:34AM +0900, Stephen J. Turnbull wrote:
> Abhilash Raj writes:
> >
> > This is a list of topics that probably needs to be discussed in detail
> > again. I tried to mention in breif about the discussions in past
> > personally with a someone or on mm-dev list.
Not in GSoC scope, this is direct to Barry (and anybody else,
including GSoC students of course, interested in core).
Barry Warsaw writes:
> I know this is a little backwards, but it's probably the best match
> for the current rule/chain model.
I have a smallish problem with this model. Speci
On Jun 16, 2013, at 01:48 AM, Stephen J. Turnbull wrote:
> > * the message is queued in incoming queue
> > * the incoming runner wakes up, finds the message and calls a few
> > functions to verify the signature of the message(assuming the function
> > already has public key of the user from so
Stephen's already given a very good response, so I'll just add a few more
thoughts.
On Jun 15, 2013, at 11:12 AM, Abhilash Raj wrote:
>* How to ensure the keys belong the email it says it does?
>
> One method proposed for this was to send a confirmation email to the email
> address, but what if
Abhilash Raj writes:
>
> This is a list of topics that probably needs to be discussed in detail
> again. I tried to mention in breif about the discussions in past
> personally with a someone or on mm-dev list. Please ignore the topics
> which you feel has already reached a inference. It is a
This is a list of topics that probably needs to be discussed in detail
again. I tried to mention in breif about the discussions in past
personally with a someone or on mm-dev list. Please ignore the topics
which you feel has already reached a inference. It is a long mail though.
* How to ensure t
24 matches
Mail list logo
