On 04/27/2013 12:45 PM, Stephen J. Turnbull wrote:
Stefan Schlott writes:
2. Your list has elevated security requirements. In this case, you can
use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way.
It's true
Abhilash Raj writes:
Hi all,
I wrote a brief summary[1] of this thread.
You've misinterpreted or mistyped a couple things I wrote:
I'm not against OAuth in general, just against Mailman being an OAuth
*provider*, or bundling one, because we can't support it properly.
Users should get auth
Richard Wackerbarth writes:
https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
returns the email address to which subscription requests should be
sent.
ABCDEFG is what? The list?
I think the short prefix /mailman/ should be reserved for traditional
and anonymous
For OAuth http://en.wikipedia.org/wiki/OAuth, you need to implement token
based auth in API, as well as a provider service because there is no open
OAuth provider service for third party API out there :-(
The provider service has to implement application registration, user auth,
token validation
Here is my take on the basic system requirements and design issues:
System Components:
* A RESTful
APIhttps://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_APIs
-
a mini-server that servers restful calls.
* A persistent store - a schemaless or relaxed datasource, e.g.
Here is an example of what it might look like for user resource returned
by the api (without any auth):
curl http://localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 1232
Cache-Control: max-age=20,must-revalidate
Expires: Sat, 27
On Apr 27, 2013, at 2:42 AM, Stephen J. Turnbull turnb...@sk.tsukuba.ac.jp
wrote:
Richard Wackerbarth writes:
https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
returns the email address to which subscription requests should be
sent.
ABCDEFG is what? The list?
Yes.
Daniel Kahn Gillmor writes:
If mailman is storing messages on-disk in an encrypted form, Stefan's
proposal mitigates the threat of an adversary with offline access to the
disk (e.g. in the event of server theft or seizure)
OK, it does that.
But in the event of that kind of threat, I think
I think that we are advocating the same approach.
Your example is better tailored to actual MM resources and can be substituted
for the one that I referenced.
Note: I am speaking conceptually. The actual hard design of the details would
be the scope of work for a GSoC project.
The easiest way to
I, and I think Stephen, are advocating the use of oAuth as a login method.
Just as BrowserID provides a third party identifier, Google, Twitter, Facebook,
etc. provide similar service through oAuth protocols. MM should be configurable
to accept those, or other enterprise-provided identifiers.
Xu Wang writes:
For OAuth http://en.wikipedia.org/wiki/OAuth, you need to
implement token based auth in API, as well as a provider service
because there is no open OAuth provider service for third party API
out there :-(
No, we don't *need* to implement *anything*. We implement what we
On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth r...@dataplex.net wrote:
Additionally, I would generalize the grouping of lists into a hierarchical
tree that represents the enterprise organization rather than aspects of the
internet namespace.
Stephen,
Barry has introduced a small amount
Richard Wackerbarth writes:
Ah so you don't mean what I wrote above, you want to represent
preferences as a table with
row = preference-owning-entity att_name att_key
Correct. But isn't it
row = preference-owning-entity att_name att_value
Yes.
Richard Wackerbarth writes:
ABCDEFG is what? The list?
Yes. But note that it is some pk provided by the list store.
pk ?
https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
would return the URI representing the list
Why have you changed the
On 27.04.2013 06:45, Stephen J. Turnbull wrote:
2. Your list has elevated security requirements. In this case, you can
use gpg-agent to manage the secret key (and its passphrase).
I don't understand what threat you propose to address in this way.
It's true that you can prevent the
On Apr 27, 2013, at 8:19 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Richard Wackerbarth writes:
ABCDEFG is what? The list?
Yes. But note that it is some pk provided by the list store.
pk ?
Primary Key == An identifier of the server's choice that identifies a unique
instance
I don't think that we have the expertise to create a secure system. At
best, we can adopt good practices and provide an obscured traffic stream. I
consider anything more to be beyond the scope of the MM project.
On Apr 27, 2013, at 8:22 AM, Stefan Schlott stefan.schl...@ulm.ccc.de wrote:
On
Richard Wackerbarth writes:
It is not necessary to have more than a flat collection of lists.
I don't know how it will be represented, but we *do* need to support
virtual hosting, where the mailman administrator delegates site
administration to the owner of the virtual host.
In fact, that
Richard Wackerbarth writes:
Primary Key == An identifier of the server's choice that identifies
a unique instance of the specified resource. It is important to
note that the client CANNOT rely on any particular scheme for
mapping other keys to this identifier.
That's true for resources
On Sat, Apr 27, 2013 at 4:59 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
Xu Wang writes:
For OAuth http://en.wikipedia.org/wiki/OAuth, you need to
implement token based auth in API, as well as a provider service
because there is no open OAuth provider service for third party API
On Sat, Apr 27, 2013 at 4:27 AM, Richard Wackerbarth r...@dataplex.netwrote:
I think that we are advocating the same approach.
Your example is better tailored to actual MM resources and can be
substituted for the one that I referenced.
Note: I am speaking conceptually. The actual hard design
21 matches
Mail list logo
