[VOTE] Apply labs crypto notice from JIRA-134

[Bernd Fondermann]

Fellow researchers,

to actually bring this crypto statement stuff forward I'd like to call a
vote. At first I thought lazy consensus would work, but I am not so sure
anymore (triggered by the comments in the thread starting here [1]), so
a vote is the safe way to go.

We have to report about the use of crypto code in Labs. Following the
instructions at [2], we should apply labs_crypto2.patch attached to JIRA
here [3] to its destination file found here[4].

Please vote:
[] Yes, apply the patch as described and kindly ask the Labs PMC chair
to send out the email as described in [2] afterwards.
[] I don't know, I don't care for this whole crypto stuff really much
[] No, don't apply the patch, there is something wrong with it. (Give
some reason, please)

The vote will not close before 2008-06-30 12:00 GMT.

Thanks for voting,

   Bernd


[1]
http://mail-archives.apache.org/mod_mbox//labs-labs/200806.mbox/%3c485BD51D.6090605@...%3e
[2] http://apache.org/dev/crypto
[3] https://issues.apache.org/jira/browse/LABS-134
[4]
https://svn.apache.org/repos/asf/infrastructure/site/trunk/xdocs/licenses/exports/index.xml

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann]

Bernd Fondermann wrote:
>
> We have to report about the use of crypto code in Labs. Following the
> instructions at [2], we should apply labs_crypto2.patch attached to JIRA
> here [3] to its destination file found here[4].
>
> Please vote:
> [+1] Yes, apply the patch as described and kindly ask the Labs PMC chair
> to send out the email as described in [2] afterwards.
(non-binding)


   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Stefano Mazzocchi]

Bernd Fondermann wrote:

> Fellow researchers,
>
> to actually bring this crypto statement stuff forward I'd like to call a
> vote. At first I thought lazy consensus would work, but I am not so sure
> anymore (triggered by the comments in the thread starting here [1]), so
> a vote is the safe way to go.
>
> We have to report about the use of crypto code in Labs. Following the
> instructions at [2], we should apply labs_crypto2.patch attached to JIRA
> here [3] to its destination file found here[4].
>
> Please vote:
> [] Yes, apply the patch as described and kindly ask the Labs PMC chair
> to send out the email as described in [2] afterwards.
> [] I don't know, I don't care for this whole crypto stuff really much
> [] No, don't apply the patch, there is something wrong with it. (Give
> some reason, please)
>
> The vote will not close before 2008-06-30 12:00 GMT.

With my chair hat on, I have a hard time executing the above since I
can't possibly be responsible of looking into every lab and hunt for
crypto stuff. I'm not even a crypto expert, I wouldn't even know what to
look for. I mean, is MD5 considered crypto? I wouldn't know.

I can go ahead and apply the existing patch, sure, no problems. But I
would like every single PI to tell me: yes, I've looked at it and it's
for for me.

Not before then.

--
Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[hen]

On Fri, Jun 27, 2008 at 8:53 AM, Stefano Mazzocchi <stefano@...> wrote:

> Bernd Fondermann wrote:
>>
>> Fellow researchers,
>>
>> to actually bring this crypto statement stuff forward I'd like to call a
>> vote. At first I thought lazy consensus would work, but I am not so sure
>> anymore (triggered by the comments in the thread starting here [1]), so a
>> vote is the safe way to go.
>>
>> We have to report about the use of crypto code in Labs. Following the
>> instructions at [2], we should apply labs_crypto2.patch attached to JIRA
>> here [3] to its destination file found here[4].
>>
>> Please vote:
>> [] Yes, apply the patch as described and kindly ask the Labs PMC chair to
>> send out the email as described in [2] afterwards.
>> [] I don't know, I don't care for this whole crypto stuff really much
>> [] No, don't apply the patch, there is something wrong with it. (Give some
>> reason, please)
>>
>> The vote will not close before 2008-06-30 12:00 GMT.
>
> With my chair hat on, I have a hard time executing the above since I can't
> possibly be responsible of looking into every lab and hunt for crypto stuff.
> I'm not even a crypto expert, I wouldn't even know what to look for. I mean,
> is MD5 considered crypto? I wouldn't know.

It isn't btw. Added to the FAQ the other week.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[William A. Rowe, Jr.]

Stefano Mazzocchi wrote:
>
> With my chair hat on, I have a hard time executing the above since I
> can't possibly be responsible of looking into every lab and hunt for
> crypto stuff. I'm not even a crypto expert, I wouldn't even know what to
> look for. I mean, is MD5 considered crypto? I wouldn't know.

Understandable, but you own the notice process as a project chair, and
must subject each incoming lablet to scrutiny (simply asking if their
code is subject to /dev/crypto policy, *before* the lab code is committed).

> I can go ahead and apply the existing patch, sure, no problems. But I
> would like every single PI to tell me: yes, I've looked at it and it's
> for for me.

Deal with one at a time; yes get this patch committed please and the notice
sent out, yesterday.

This is not the subject of a vote, as an alternative Stefano would be happy
to shutter the offending svn repositories.  Get Stefano your patches.

Thanks Vysper for following through.

BadCA is a weird one, it plugs into an interface in APR to OpenSSL that is
currently mothballed in a sandbox and looking for attention to get it ready
to be reintegrated into trunk.  But APR is still on the hook for providing
notice (we already had) even though it lives in a sandbox.  So if you simply
copy APR's style of notice w.r.t. OpenSSL, BadCA should be covered.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann]

Stefano Mazzocchi wrote:

> Bernd Fondermann wrote:
>> Fellow researchers,
>>
>> to actually bring this crypto statement stuff forward I'd like to call
>> a vote. At first I thought lazy consensus would work, but I am not so
>> sure anymore (triggered by the comments in the thread starting here
>> [1]), so a vote is the safe way to go.
>>
>> We have to report about the use of crypto code in Labs. Following the
>> instructions at [2], we should apply labs_crypto2.patch attached to
>> JIRA here [3] to its destination file found here[4].
>>
>> Please vote:
>> [] Yes, apply the patch as described and kindly ask the Labs PMC chair
>> to send out the email as described in [2] afterwards.
>> [] I don't know, I don't care for this whole crypto stuff really much
>> [] No, don't apply the patch, there is something wrong with it. (Give
>> some reason, please)
>>
>> The vote will not close before 2008-06-30 12:00 GMT.
>
> With my chair hat on, I have a hard time executing the above since I
> can't possibly be responsible of looking into every lab and hunt for
> crypto stuff. I'm not even a crypto expert, I wouldn't even know what to
> look for. I mean, is MD5 considered crypto? I wouldn't know.
>
> I can go ahead and apply the existing patch, sure, no problems. But I
> would like every single PI to tell me: yes, I've looked at it and it's
> for for me.

Well, as the PI for Vysper I affirm to you: the patch is absolutely OK.
It contains only Vysper-related stuff and covers every crypto in this
lab. Please ask any specific question and I will answer.

I cannot speak for the other PIs, but delaying this patch would
eventually harm my lab which I am unlikely to be happy about. So I need
your help here.
(I'd even would commit the patch myself, but not without being ratified
by some PMC votes.)

It's clear that one person (chair or not) cannot oversee all lablings.
But the PMC as a whole is tasked with that and there are many
experienced apache people on it. So originally there should be no lack
of know-how of how to deal with crypto reporting and oversight in
general. But there seems to be little overlap between PMC members and
active lab committers. Maybe this is partly the reason why I feel this
issue is so hard to get sorted.

Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Mads Toftum]

On Fri, Jun 27, 2008 at 11:45:45AM -0500, William A. Rowe, Jr. wrote:
> BadCA is a weird one, it plugs into an interface in APR to OpenSSL that is
> currently mothballed in a sandbox and looking for attention to get it ready
> to be reintegrated into trunk.  But APR is still on the hook for providing
> notice (we already had) even though it lives in a sandbox.  So if you
> simply
> copy APR's style of notice w.r.t. OpenSSL, BadCA should be covered.
>
GPG will most likely be added to the mix as well given the planned
design, but other than that I think that'll be ok. I was looking at the
notice for httpd earlier and that one deviates from what BadCA needs
because crypto isn't optional here.
As for the bit about the crypto living on an obscure branch of apr, that
wasn't the case last time BadCA was active - at that point the code was
in trunk.

vh

Mads Toftum
--
http://soulfood.dk

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[William A. Rowe, Jr.]

Mads Toftum wrote:
> GPG will most likely be added to the mix as well given the planned
> design, but other than that I think that'll be ok. I was looking at the
> notice for httpd earlier and that one deviates from what BadCA needs
> because crypto isn't optional here.

Yes - it is a little different, and if we bind later to some libgpg we
can address it then.

> As for the bit about the crypto living on an obscure branch of apr, that
> wasn't the case last time BadCA was active - at that point the code was
> in trunk.

Right, I was just making the observation that apr is still on the hook
even though it isn't a shipping product, and for BadCA I hope we do finally
round out the API to satisfy the objections from dev@apr (and ship a 1.4.0
officially that BadCA can consume).

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[David Reid-3]

William A. Rowe, Jr. wrote:
> Mads Toftum wrote:
>> GPG will most likely be added to the mix as well given the planned
>> design, but other than that I think that'll be ok. I was looking at the
>> notice for httpd earlier and that one deviates from what BadCA needs
>> because crypto isn't optional here.
>
> Yes - it is a little different, and if we bind later to some libgpg we
> can address it then.

There are plans to bind to some gpg libs.

>
>> As for the bit about the crypto living on an obscure branch of apr, that
>> wasn't the case last time BadCA was active - at that point the code was
>> in trunk.
>
> Right, I was just making the observation that apr is still on the hook
> even though it isn't a shipping product, and for BadCA I hope we do finally
> round out the API to satisfy the objections from dev@apr (and ship a 1.4.0
> officially that BadCA can consume).

Erm, well, badca hasn't ever been related to APR, so I was a little
confused by the initial assertion. I'll have a look and get a notice
added, though I'm not 100% sure where it needs to go.

To clarify - badca isn't planned, nor has it ever been planned, to be a
consumer of apr.

david

>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>
> !DSPAM:16,4865259273203999710783!
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[William A. Rowe, Jr.]

David Reid wrote:
>
> To clarify - badca isn't planned, nor has it ever been planned, to be a
> consumer of apr.

Then color me confused, I thought BadCA was just one of several reasons to
add ssl support to apr.  Glad to know apr isn't a showstopper, here.

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[David Reid-3]

William A. Rowe, Jr. wrote:
> David Reid wrote:
>>
>> To clarify - badca isn't planned, nor has it ever been planned, to be a
>> consumer of apr.
>
> Then color me confused, I thought BadCA was just one of several reasons to
> add ssl support to apr.  Glad to know apr isn't a showstopper, here.

No idea where that came from, but it's never been part of the plan wrt
BaDCA.

david

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>
> !DSPAM:16,48652e3373209974735230!
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Mads Toftum]

On Fri, Jun 27, 2008 at 12:37:40PM -0500, William A. Rowe, Jr. wrote:
> Right, I was just making the observation that apr is still on the hook
> even though it isn't a shipping product, and for BadCA I hope we do finally
> round out the API to satisfy the objections from dev@apr (and ship a 1.4.0
> officially that BadCA can consume).
>
That would indeed be goodness even if BadCA doesn't need it.
BadCA uses openssl certificate functions through its own python
interface, iirc, the main focus of openssl support in apr was to get ssl
support for connections.

vh

Mads Toftum
--
http://soulfood.dk

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[David Reid-3]

Mads Toftum wrote:

> On Fri, Jun 27, 2008 at 12:37:40PM -0500, William A. Rowe, Jr. wrote:
>> Right, I was just making the observation that apr is still on the hook
>> even though it isn't a shipping product, and for BadCA I hope we do finally
>> round out the API to satisfy the objections from dev@apr (and ship a 1.4.0
>> officially that BadCA can consume).
>>
> That would indeed be goodness even if BadCA doesn't need it.
> BadCA uses openssl certificate functions through its own python
> interface, iirc, the main focus of openssl support in apr was to get ssl
> support for connections.

That and to provide the ability to decouple from openssl so that we had
more flexibility. Maybe one day...

>
> vh
>
> Mads Toftum


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann]

David Reid wrote:

> William A. Rowe, Jr. wrote:
>> Mads Toftum wrote:
>>> GPG will most likely be added to the mix as well given the planned
>>> design, but other than that I think that'll be ok. I was looking at the
>>> notice for httpd earlier and that one deviates from what BadCA needs
>>> because crypto isn't optional here.
>> Yes - it is a little different, and if we bind later to some libgpg we
>> can address it then.
>
> There are plans to bind to some gpg libs.
>
>>> As for the bit about the crypto living on an obscure branch of apr, that
>>> wasn't the case last time BadCA was active - at that point the code was
>>> in trunk.
>> Right, I was just making the observation that apr is still on the hook
>> even though it isn't a shipping product, and for BadCA I hope we do finally
>> round out the API to satisfy the objections from dev@apr (and ship a 1.4.0
>> officially that BadCA can consume).
>
> Erm, well, badca hasn't ever been related to APR, so I was a little
> confused by the initial assertion. I'll have a look and get a notice
> added, though I'm not 100% sure where it needs to go.
>
> To clarify - badca isn't planned, nor has it ever been planned, to be a
> consumer of apr.

But BadCA is a consumer of OpenSSL, right? So the notice needed with
respect to labs would be something along the lines of the 'Product'
section like here:

https://issues.apache.org/jira/secure/attachment/12384406/labs_crypto2.patch

Should be straightforward.

   Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann]

Bernd Fondermann wrote:

> Fellow researchers,
>
> to actually bring this crypto statement stuff forward I'd like to call a
> vote. At first I thought lazy consensus would work, but I am not so sure
> anymore (triggered by the comments in the thread starting here [1]), so
> a vote is the safe way to go.
>
> We have to report about the use of crypto code in Labs. Following the
> instructions at [2], we should apply labs_crypto2.patch attached to JIRA
> here [3] to its destination file found here[4].
>
> Please vote:
> [] Yes, apply the patch as described and kindly ask the Labs PMC chair
> to send out the email as described in [2] afterwards.
> [] I don't know, I don't care for this whole crypto stuff really much
> [] No, don't apply the patch, there is something wrong with it. (Give
> some reason, please)
>
> The vote will not close before 2008-06-30 12:00 GMT.

I am cancelling this vote, it's unlikely any more votes will be cast.
There were no binding votes, so the vote fails.

Don't know what is next...

   Bernd



---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[David Reid-3]

Bernd Fondermann wrote:

> Bernd Fondermann wrote:
>> Fellow researchers,
>>
>> to actually bring this crypto statement stuff forward I'd like to call
>> a vote. At first I thought lazy consensus would work, but I am not so
>> sure anymore (triggered by the comments in the thread starting here
>> [1]), so a vote is the safe way to go.
>>
>> We have to report about the use of crypto code in Labs. Following the
>> instructions at [2], we should apply labs_crypto2.patch attached to
>> JIRA here [3] to its destination file found here[4].
>>
>> Please vote:
>> [] Yes, apply the patch as described and kindly ask the Labs PMC chair
>> to send out the email as described in [2] afterwards.
>> [] I don't know, I don't care for this whole crypto stuff really much
>> [] No, don't apply the patch, there is something wrong with it. (Give
>> some reason, please)
>>
>> The vote will not close before 2008-06-30 12:00 GMT.
>
> I am cancelling this vote, it's unlikely any more votes will be cast.
> There were no binding votes, so the vote fails.
>
> Don't know what is next...

As has been pointed out, this just needs to be applied. The vote really
wasn't needed...

The need to submit a crypto report should probably be added to the
requirements for a lab as it's now board mandated and each PI should be
contacted by Stefano and asked to submit one.

Chalk up another one for bureaucracy :-(

david

>
>   Bernd
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@...
> For additional commands, e-mail: labs-help@...
>
>
> !DSPAM:16,4867823973201126917305!
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[William A. Rowe, Jr.]

David Reid wrote:
>
> The need to submit a crypto report should probably be added to the
> requirements for a lab as it's now board mandated and each PI should be
> contacted by Stefano and asked to submit one.
>
> Chalk up another one for bureaucracy :-(

C'mon David, it is not because this is 'newly' board-mandated, it was always
true of @apache.org by the us gov't.  Unfortunately there was a disconnect
between opening the floodgates of allowing crypto (starting when httpd was
finally allowed to have mod_ssl right here at the foundation) who did so
by notifying the gov't, and a flood of crypto that was not accounted for
before the more easy-to-follow /licenses/exports/ pages were in place.


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...

[Bernd Fondermann]

David Reid wrote:

> Bernd Fondermann wrote:
>> Bernd Fondermann wrote:
>>> Fellow researchers,
>>>
>>> to actually bring this crypto statement stuff forward I'd like to call
>>> a vote. At first I thought lazy consensus would work, but I am not so
>>> sure anymore (triggered by the comments in the thread starting here
>>> [1]), so a vote is the safe way to go.
>>>
>>> We have to report about the use of crypto code in Labs. Following the
>>> instructions at [2], we should apply labs_crypto2.patch attached to
>>> JIRA here [3] to its destination file found here[4].
>>>
>>> Please vote:
>>> [] Yes, apply the patch as described and kindly ask the Labs PMC chair
>>> to send out the email as described in [2] afterwards.
>>> [] I don't know, I don't care for this whole crypto stuff really much
>>> [] No, don't apply the patch, there is something wrong with it. (Give
>>> some reason, please)
>>>
>>> The vote will not close before 2008-06-30 12:00 GMT.
>> I am cancelling this vote, it's unlikely any more votes will be cast.
>> There were no binding votes, so the vote fails.
>>
>> Don't know what is next...
>
> As has been pointed out, this just needs to be applied.

But applying seems to be a problem here. Nobody did it yet.

> The vote really
> wasn't needed...

Votes raise more awareness.
And it would have been needed to ratify that I will do it. But now I won't.

> The need to submit a crypto report should probably be added to the
> requirements for a lab as it's now board mandated and

+0

 > each PI should be
> contacted by Stefano and asked to submit one.

That has happend looong ago.

> Chalk up another one for bureaucracy :-(

Yes, nobody likes to do this, we are forced to do this because of US
policy.
But this topic could long been resolved if every PI took one minute to
complete a well-documented simple process by adding some very very
simple XML to an already existing template.

(Or even simpler: run 'svn rm <lab>' and you don't even need to read any
annyoing documents.)

Just do it, you will feel better afterwards. :-)

   Bernd


---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscribe@...
For additional commands, e-mail: labs-help@...