Re: Committer's name misspelled in Whimsy roster

[Chris Lambertus]

> On Aug 15, 2024, at 5:38 PM, Nathan Hartman  wrote:
> 
> Hi all,
> 
> Please CC me on replies as I'm not subscribed.
> 
> On Apache Subversion's roster, Whimsy shows one of our PMC member's name
> with incorrect spelling: Timofei Zhakov's first name is shown as Timofey (y
> instead of i; i is correct).
> 
> Whimsy also uses the incorrect spelling when it generates the text "Timofey
> Zhakov was added to the PMC on 2024-06-24" (note the y) for our reports.
> 
> Timofei has confirmed to me that his Public Name is correctly configured as
> Timofei in his id.apache.org.


I checked his LDAP record and his ICLA both have the correct (Timofei) spelling.

The committee-into.txt record needs to be updated by the project per 
https://www.apache.org/dev/pmc.html

-Chris



> There was some confusion regarding his spelling when his account was
> created, due to changes in how Cyrillic is transliterated to Latin.
> 
> This leads me to believe that an incorrect spelling lingers somewhere in
> our systems, and Whimsy is picking that up.
> 
> So the question is: how/where/what needs to be fixed so that Timofei's name
> will be spelled correctly everywhere?
> 
> Thanks,
> Nathan

[jira] [Commented] (WHIMSY-402) remove "GitHub username" from details page

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737913#comment-17737913
 ] 

Chris Lambertus commented on WHIMSY-402:


I agree with Dave in that this field should not be removed. I believe it is 
important for ASF committers to be able to share their various identities as 
viewable in the Whimsy Roster. While the github field in LDAP is not currently 
used for technical mapping of ASF account and Github account, it remains a 
valuable tool for committers to visually match ASF IDs with Github IDs. LDAP is 
a perfect location for this type of data.

I do believe it is important to disambiguate the fact that the LDAP field is 
not _*currently*_ used by Boxer, but I also feel a case could be made to have 
Boxer automatically populate this field. I'll describe a proposal for such and 
bring it to an Infra list for further discussion.

> remove "GitHub username" from details page
> --
>
> Key: WHIMSY-402
> URL: https://issues.apache.org/jira/browse/WHIMSY-402
> Project: Whimsy
>  Issue Type: Improvement
>  Components: Roster
>Reporter: Greg Stein
>Priority: Minor
>
> The GitHub username is no longer used by Infrastructure processes. The 
> linkage between LDAP accounts and GitHub usernames is contained within the 
> gitbox service. LDAP is not used as a storage mechanism for that linkage.
> As a result, I believe the field is obsolete and (worse) potentially 
> confusing with the account *actually* linked to an LDAP account. I think it 
> should be removed from the UI. (and eventually from LDAP, but that's 
> orthogonal)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Update email addresses in whimsy/committer

[Chris Lambertus]

> On Feb 27, 2023, at 2:44 PM, sebb  wrote:
> 
> On Mon, 27 Feb 2023 at 21:30, Craig Russell  wrote:
>> 
>> I see that I can add/update/delete email addresses using id.apache.org:
>> Forwarding email address:
> 
> That's the LDAP 'mail' attribute.

Correct, the content of that LDAP attribute is placed in .qmail-$uid and is 
where your @a.o email is forwarded.

>> Email (other):
> 
> That's asf-committer-email plus the email address from the ICLA.

asf-committer-email is a synthesized address of $u...@apache.org. It is used by 
various ldap-enabled tools so that we do not expose the committer's personal 
email address via systems like jira, cwiki, jenkins, buildbot, etc.

It is not editable. See 
https://cwiki.apache.org/confluence/display/INFRA/LDAP+at+the+ASF

The email address from the ICLA is -not- stored in LDAP, and is thus not 
editable by id.a.o. I do not know where whimsy obtains that information.

>> It seems that whimsy allows updates to forwarded to and (alt) but not 
>> (other).
>> 
>> So:
>> What/why is there an (alt) address in whimsy?
> 
> I assume it's to allow people to associate other emails with their login.

There are very few references to asf-altEmail in our code. It is possible that 
this was something under development in the past but never implemented. I will 
look into this further and report back.

>> Why can whimsy not update email (other)
> 
> See above.
> 
>> What is (other) used for?
> 
> Not entirely sure.

These fields may be useful to inform the user of what their ICLA email address 
is, or what their committer email address is, but those two things are 
informational only, and IMO should be broken down into two fields:

ICLA Email address on file:# file a new ICLA to change
ASF Committer address: $u...@apache.org # you can advertise this

The asf-committer-email address will never be editable. It would only change if 
the user changed their UID.

Hope this helps.

-Chris


> 
>> Thanks,
>> Craig
>> 
>> Craig L Russell
>> c...@apache.org
>> 

Re: ldap "meta" ou

[Chris Lambertus]

> On Jun 15, 2022, at 4:15 PM, sebb  wrote:
> 
> On Mon, 13 Jun 2022 at 19:12, Chris Lambertus  <mailto:c...@apache.org>> wrote:




>> Does this seem like a reasonable approach?
> 
> It seems quite complicated compared with just fixing the existing
> script to generate updates rather than recreating everything.

Yes, I believe that is the option I will go with.

Thanks for the input.

-Chris


> 
>> -Chris
>> 
>> 
>>> 
>>>>> This would minimise process changes as well as minimising LDAP updates.
>>>> 
>>>> This is the goal.
>>>> 
>>>>> In case there are Infra scripts that update owners it would make sense
>>>>> to keep a regular check on the consistency of the lists.
>>>> 
>>>> Yes, I have been looking to see if there are any infra scripts which would 
>>>> need to be updated, but I currently believe the only active tooling is 
>>>> within whimsy.
>>>> 
>>>> -Chris
>>> 
>>> - Sam Ruby
>>> 
>>>>> Sebb
>>>>> On Mon, 13 Jun 2022 at 00:32, Sam Ruby  wrote:
>>>>>> 
>>>>>> From a whimsy requirements perspective, the key requirement is that
>>>>>> PMC members can update LDAP the PMC (i.e., both the PMC and committers
>>>>>> lists).
>>>>>> 
>>>>>> On Sun, Jun 12, 2022 at 6:56 PM sebb  wrote:
>>>>>>> 
>>>>>>> On Sun, 12 Jun 2022 at 21:26, Chris Lambertus  wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi folks,
>>>>>>>> 
>>>>>>>> I have been working on some updates to the LDAP service, and I would 
>>>>>>>> like to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the 
>>>>>>>> process which manages it.)
>>>>>>>> 
>>>>>>>> Some history -- this ou was created to address a problem which arose 
>>>>>>>> after project groups were converted to member/owner (INFRA-16188). The 
>>>>>>>> Atlassian Crowd service that feeds authentication and authorization 
>>>>>>>> for Jira and Confluence does not understand the "owner" concept.
>>>>>>>> 
>>>>>>>> Infra had previously created local roles in cwiki and jira, and 
>>>>>>>> generally pushed maintenance of memberships of said roles to the 
>>>>>>>> project owners defined within cwiki and jira. Over time this grew 
>>>>>>>> cumbersome, and we elected to switch to LDAP-based groups, but we only 
>>>>>>>> had access via Crowd to the attr=member version of the groups, so we 
>>>>>>>> could not assign PMC-based roles.
>>>>>>>> 
>>>>>>>> Because of this, I created a stop-gap process which drops and reloads 
>>>>>>>> ou=meta nightly, populating 
>>>>>>>> ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of 
>>>>>>>> the PMC members. This process is awkward, and causes problems with the 
>>>>>>>> LDAP audit logging system.
>>>>>>>> 
>>>>>>>> I would like to gather feedback on re-creating and maintaining the 
>>>>>>>> ou=pmc tree in parallel with the owner/member paradigm that is now in 
>>>>>>>> place, specifically to support Crowd-based applications (which now 
>>>>>>>> also include JFrog/artifactory,) or other 3rd party tooling which may 
>>>>>>>> not understand member/owner.
>>>>>>>> 
>>>>>>>> At this time, I believe the only ASF tooling which creates or modifies 
>>>>>>>> the owner attribute of project groups is Whimsy, so any code 
>>>>>>>> adjustments would likely have to happen here.
>>>>>>> 
>>>>>>> AFAIK Whimsy is not the only place where accounts are created and PMC
>>>>>>> memberships updated; there are likely some Infra scripts that do so.
>>>>>>> 
>>>>>>> It's not clear to me whether the existing owner attributes will be kept 
>>>>>>> or not.
>>>>>>> Indeed I'm not clear what the proposal is.
>>>>>>> 
>>>>>>>> What are your thoughts?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Chris
>>>>>>>> ASF Infra

Re: ldap "meta" ou

[Chris Lambertus]

> On Jun 13, 2022, at 10:57 AM, Sam Ruby  wrote:
> 
> On Mon, Jun 13, 2022 at 1:06 PM Chris Lambertus  <mailto:c...@apache.org>> wrote:
>> 
>>> On Jun 12, 2022, at 4:54 PM, sebb  wrote:
>>> 
>>> If the problem is just that recreating ou=meta is messy, then there
>>> are other solutions.
>>> 
>>> For example, it should not be too difficult to compare the lists and
>>> only update those which have changed.
>>> Probably can also speed this up by comparing last updated dates.
>>> 
>>> It might also make sense to enhance Whimsy to update the ou=meta list
>>> at the same time as the owners.
>>> As Sam points out this would require that the karma needed must agree
>>> with the karma for owners.
>> 
>> Yes, this whimsy enhancement is ultimately what my proposal is -- update 
>> whimsy to maintain the pmc groups with instead of having a separate 
>> drop/parse/create system as we do now. I am not sure what you mean by "karma 
>> needed must agree" though. Are you referring to LDAP ACLs? if so, the policy 
>> would already allow this if the ou is under ou=groups.
> 
> I preface the following by stating that what I am about to say may be
> a result of my ignorance of LDAP configuration capabilities, but I
> believe the crux of the issue can be found on the following line:
> 
> https://github.com/apache/infrastructure-p6/blob/d0e1160c2a5d0a7f6b9197893f126f80013f/modules/ldapserver/templates/slapd.conf.erb#L321
>  
> <https://github.com/apache/infrastructure-p6/blob/d0e1160c2a5d0a7f6b9197893f126f80013f/modules/ldapserver/templates/slapd.conf.erb#L321>
> 
> What that line says is that (in addition to root, secretary, pmc
> chairs, and the secretarial team) members of [P]PMCs can edit their
> own group.  So, for example, PMC members (owners) can add/remove
> committers (members).

I see what you mean. If whimsy is using the auth context of the logged-in user, 
then they would not be able to write to a theoretical 
cn=whimsy-pmc,ou=pmcs,ou=group,dc=apache,dc=org because the group such as 
cn=whimsy-pmc would only contain 'member' attributes. 

Given the ACL, this -would- work if they were an ASF Member, a PMC Chair, or 
Secretary. The workaround here would be to add both owner and member 
attributes, but then that begs the question, how are owners initially added? By 
the Secretary?

> Now for a thought experiment.  If 'owner' is problematic for some
> tools, then what would an LDAP configuration look like with NO owners?

It would look the same as it did prior to the owner/member migration, with a 
separate objects for cn=project and cn=project-pmc. Since cn=project already 
works fine, we just need to (re)add and populate cn=project-pmc with a member 
attribute. (And possibly also a matching owner attribute as described above.)

> What we would need is the ability to specify "members of groups in
> this subtree are authorized to write to CORRESPONDING groups in
> ANOTHER subtree".  We have the ability to say that "members of THIS
> SPECIFIC group can write to THAT SPECIFIC group".  And the ability to
> say "members of THIS SPECIFIC group can update that entire SUBTREE".
> But as far as I know (and this may very well be my ignorance), there
> is no way to grant corresponding members of one subtree update access
> to another subtree.

I'm not sure about this either. I could easily update the genmeta script to add 
both owner and member values instead of just member values, which would then 
allow the ACL to work as expected.

Does this seem like a reasonable approach?

-Chris


> 
>>> This would minimise process changes as well as minimising LDAP updates.
>> 
>> This is the goal.
>> 
>>> In case there are Infra scripts that update owners it would make sense
>>> to keep a regular check on the consistency of the lists.
>> 
>> Yes, I have been looking to see if there are any infra scripts which would 
>> need to be updated, but I currently believe the only active tooling is 
>> within whimsy.
>> 
>> -Chris
> 
> - Sam Ruby
> 
>>> Sebb
>>> On Mon, 13 Jun 2022 at 00:32, Sam Ruby  wrote:
>>>> 
>>>> From a whimsy requirements perspective, the key requirement is that
>>>> PMC members can update LDAP the PMC (i.e., both the PMC and committers
>>>> lists).
>>>> 
>>>> On Sun, Jun 12, 2022 at 6:56 PM sebb  wrote:
>>>>> 
>>>>> On Sun, 12 Jun 2022 at 21:26, Chris Lambertus  wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi folks,
>>>>>> 
>

Re: ldap "meta" ou

[Chris Lambertus]

> On Jun 12, 2022, at 4:54 PM, sebb  wrote:
> 
> If the problem is just that recreating ou=meta is messy, then there
> are other solutions.
> 
> For example, it should not be too difficult to compare the lists and
> only update those which have changed.
> Probably can also speed this up by comparing last updated dates.
> 
> It might also make sense to enhance Whimsy to update the ou=meta list
> at the same time as the owners.
> As Sam points out this would require that the karma needed must agree
> with the karma for owners.

Yes, this whimsy enhancement is ultimately what my proposal is -- update whimsy 
to maintain the pmc groups with instead of having a separate drop/parse/create 
system as we do now. I am not sure what you mean by "karma needed must agree" 
though. Are you referring to LDAP ACLs? if so, the policy would already allow 
this if the ou is under ou=groups.

> This would minimise process changes as well as minimising LDAP updates.

This is the goal.

> In case there are Infra scripts that update owners it would make sense
> to keep a regular check on the consistency of the lists.

Yes, I have been looking to see if there are any infra scripts which would need 
to be updated, but I currently believe the only active tooling is within whimsy.

-Chris


> 
> Sebb
> On Mon, 13 Jun 2022 at 00:32, Sam Ruby  wrote:
>> 
>> From a whimsy requirements perspective, the key requirement is that
>> PMC members can update LDAP the PMC (i.e., both the PMC and committers
>> lists).
>> 
>> On Sun, Jun 12, 2022 at 6:56 PM sebb  wrote:
>>> 
>>> On Sun, 12 Jun 2022 at 21:26, Chris Lambertus  wrote:
>>>> 
>>>> 
>>>> Hi folks,
>>>> 
>>>> I have been working on some updates to the LDAP service, and I would like 
>>>> to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the process 
>>>> which manages it.)
>>>> 
>>>> Some history -- this ou was created to address a problem which arose after 
>>>> project groups were converted to member/owner (INFRA-16188). The Atlassian 
>>>> Crowd service that feeds authentication and authorization for Jira and 
>>>> Confluence does not understand the "owner" concept.
>>>> 
>>>> Infra had previously created local roles in cwiki and jira, and generally 
>>>> pushed maintenance of memberships of said roles to the project owners 
>>>> defined within cwiki and jira. Over time this grew cumbersome, and we 
>>>> elected to switch to LDAP-based groups, but we only had access via Crowd 
>>>> to the attr=member version of the groups, so we could not assign PMC-based 
>>>> roles.
>>>> 
>>>> Because of this, I created a stop-gap process which drops and reloads 
>>>> ou=meta nightly, populating 
>>>> ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of the 
>>>> PMC members. This process is awkward, and causes problems with the LDAP 
>>>> audit logging system.
>>>> 
>>>> I would like to gather feedback on re-creating and maintaining the ou=pmc 
>>>> tree in parallel with the owner/member paradigm that is now in place, 
>>>> specifically to support Crowd-based applications (which now also include 
>>>> JFrog/artifactory,) or other 3rd party tooling which may not understand 
>>>> member/owner.
>>>> 
>>>> At this time, I believe the only ASF tooling which creates or modifies the 
>>>> owner attribute of project groups is Whimsy, so any code adjustments would 
>>>> likely have to happen here.
>>> 
>>> AFAIK Whimsy is not the only place where accounts are created and PMC
>>> memberships updated; there are likely some Infra scripts that do so.
>>> 
>>> It's not clear to me whether the existing owner attributes will be kept or 
>>> not.
>>> Indeed I'm not clear what the proposal is.
>>> 
>>>> What are your thoughts?
>>>> 
>>>> Thanks,
>>>> Chris
>>>> ASF Infra
>>>> 
>>>> 

ldap "meta" ou

[Chris Lambertus]

Hi folks,

I have been working on some updates to the LDAP service, and I would like to 
get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the process which 
manages it.)

Some history -- this ou was created to address a problem which arose after 
project groups were converted to member/owner (INFRA-16188). The Atlassian 
Crowd service that feeds authentication and authorization for Jira and 
Confluence does not understand the "owner" concept. 

Infra had previously created local roles in cwiki and jira, and generally 
pushed maintenance of memberships of said roles to the project owners defined 
within cwiki and jira. Over time this grew cumbersome, and we elected to switch 
to LDAP-based groups, but we only had access via Crowd to the attr=member 
version of the groups, so we could not assign PMC-based roles.

Because of this, I created a stop-gap process which drops and reloads ou=meta 
nightly, populating ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with 
attr=member of the PMC members. This process is awkward, and causes problems 
with the LDAP audit logging system. 

I would like to gather feedback on re-creating and maintaining the ou=pmc tree 
in parallel with the owner/member paradigm that is now in place, specifically 
to support Crowd-based applications (which now also include JFrog/artifactory,) 
or other 3rd party tooling which may not understand member/owner. 

At this time, I believe the only ASF tooling which creates or modifies the 
owner attribute of project groups is Whimsy, so any code adjustments would 
likely have to happen here.

What are your thoughts?

Thanks,
Chris
ASF Infra

whimsy subscription data

[Chris Lambertus]

Hi folks,

Could you please refresh my memory or point me at some documentation that 
describes how whimsy currently communicates with hermes vis a vis mailing list 
information? I am looking to understand the scope of changes which will be 
needed as we migrate to its replacement.

Thanks,
Chris

[jira] [Commented] (WHIMSY-383) root@ needs access to ICLAs

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503021#comment-17503021
 ] 

Chris Lambertus commented on WHIMSY-383:


No auth changes are needed as far as I can tell. Sam's change now displays the 
ICLA link to SVN, which Infra already has access to, so I consider this 
complete. Thanks!

 

> root@ needs access to ICLAs
> ---
>
> Key: WHIMSY-383
> URL: https://issues.apache.org/jira/browse/WHIMSY-383
> Project: Whimsy
>  Issue Type: Improvement
>  Components: General
>    Reporter: Chris Lambertus
>Priority: Minor
>
> People in the infrastructure-root LDAP group need to be able to view ICLAs 
> and Member forms for occasional identity verification and operational 
> requirements. We can already access these in svn, of course, but having them 
> available to us in Whimsy would be very convenient. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (WHIMSY-383) root@ needs access to ICLAs

[Chris Lambertus (Jira)]

Chris Lambertus created WHIMSY-383:
--

 Summary: root@ needs access to ICLAs
 Key: WHIMSY-383
 URL: https://issues.apache.org/jira/browse/WHIMSY-383
 Project: Whimsy
  Issue Type: Improvement
  Components: General
Reporter: Chris Lambertus


People in the infrastructure-root LDAP group need to be able to view ICLAs and 
Member forms for occasional identity verification and operational requirements. 
We can already access these in svn, of course, but having them available to us 
in Whimsy would be very convenient. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: test LDAP instance downtime/updates

[Chris Lambertus]

> On Oct 19, 2021, at 2:14 AM, sebb  wrote:
> 
> On Tue, 19 Oct 2021 at 05:23, Chris Lambertus  wrote:
>> 
>> It will not currently work on ASF hosts against idmtest without setting 
>> TLS_REQCERT=never because the puppet-based ldap.conf is configured to only 
>> use the existing self-signed CA cert:
>> 
>> 
>> 
>> TLS_REQCERT=never ldapsearch -H ldaps://idmtest1-ec2-va.apache.org:636 -W -b 
>> "dc=apache,dc=org" -L -D "uid=cml,ou=people,dc=apache,dc=org" uid=cml
> 
> Surely that should be LDAPTLS_REQCERT= ... ?

Apparently so.




>> What is the command line/bind DN you are specifying when you get the error 
>> 32?

> # search result
> No such object (32)
> 
> # numResponses: 1
> 
> It assume you have karma to log in to Whimsy so you could try it for yourself.


I have, and it works, but I have additional (apldap) karma. I will look into 
this further, it is likely related to DSN access. I'll get back to you... 


Thanks for testing.
-C





> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Oct 15, 2021, at 4:47 AM, sebb  wrote:
>>> 
>>> On Thu, 7 Oct 2021 at 19:53, Chris Lambertus >> <mailto:c...@apache.org>> wrote:
>>> 
>>>> Authenticated bind example:
>>>> 
>>>> 
>>>> 
>>>> $ ldapsearch -H ldaps://idmtest1-ec2-va.apache.org:636 -W -b
>>>> "dc=apache,dc=org" -L -D "uid=cml,ou=people,dc=apache,dc=org" uid=cml
>>>> Enter LDAP Password:
>>>> version: 1
>>>> 
>>>> #
>>>> # LDAPv3
>>>> # base  with scope subtree
>>>> # filter: uid=cml
>>>> # requesting: ALL
>>>> #
>>>> 
>>>> # cml, people, apache.org
>>>> dn: uid=cml,ou=people,dc=apache,dc=org
>>>> [snip]
>>>> 
>>>> 
>>>> 
>>> Does not work for me on the whimsy host:
>>> 
>>> 
>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>> 
>>> 
>>> Nor on my macOS system:
>>> 
>>> No such object (32)
>>> 
>>> (Yes, I did change the bind details)
>>> 
>>> If I enter an incorrect password on macOS, I get:
>>> 
>>> ldap_bind: Invalid credentials (49)
>>> 
>>> This shows the server has been contacted at least.
>>> However using a bad password on Whimsy makes no difference.
>>> 
>>> Any tooling relying on UN-authenticated bind will need to switch to using a
>>>> role account. We're starting a process of locating and adjusting any of
>>>> these use cases. There are also a number of cases where tools like
>>>> 'ldapsearch' will use the nss_ldap bind account which is defined in
>>>> /etc/ldap/ldap.conf, so sometimes it appears the tools work without
>>>> passwords, but they are actually using the ldap.conf credentials.
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Oct 6, 2021, at 7:40 PM, Matt Sicker  wrote:
>>>>> 
>>>>> What authentication methods are supported now? I remember being unable
>>>> to find an incantation of ldapsearch that could authenticate.
>>>>> 
>>>>> Matt Sicker
>>>>> 
>>>>>> On Oct 6, 2021, at 18:40, Chris Lambertus  wrote:
>>>>>> 
>>>>>> Hi folks, just to let you know, my primary testing and implementation
>>>> of replication between idmtest1-ec2-va and idmtest2-ec2-va is complete. The
>>>> next stage in testing may be more disruptive -- the slapd.conf ACLs have
>>>> been changed to prevent unauthenticated access to the LDAP directory.
>>>>>> 
>>>>>> If your project has the capability to test, I would be interested to
>>>> know if Whimsy still functions properly with these security and privacy
>>>> enhancements in place. There will be a more broad discussion on this topic
>>>> brought to Infra lists once initial validation is complete.
>>>>>> 
>>>>>> Cheers,
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Sep 29, 2021, at 11:15 AM, Chris Lambertus  wrote:
>>>>>>> 
>>>>>>> FYI,
>>>>>>> 
>>>>>>> In https://issues.apache.org/jira/browse/INFRA-22091 <
>>>> https://issues.apache.org/jira/browse/INFRA-22091> a test ldap instance
>>>> was provided to the Whimsy project. This is a notification that Infra will
>>>> be performing work on that host over the next few days. The system may be
>>>> down and data may be unavailable during various operations. I will reply
>>>> here when work is completed. You may continue using the service, but you
>>>> may get timeouts or null results.
>>>>>>> 
>>>>>>> -Chris
>> 

Re: test LDAP instance downtime/updates

[Chris Lambertus]

It will not currently work on ASF hosts against idmtest without setting 
TLS_REQCERT=never because the puppet-based ldap.conf is configured to only use 
the existing self-signed CA cert:



TLS_REQCERT=never ldapsearch -H ldaps://idmtest1-ec2-va.apache.org:636 -W -b 
"dc=apache,dc=org" -L -D "uid=cml,ou=people,dc=apache,dc=org" uid=cml


What is the command line/bind DN you are specifying when you get the error 32? 






> On Oct 15, 2021, at 4:47 AM, sebb  wrote:
> 
> On Thu, 7 Oct 2021 at 19:53, Chris Lambertus  <mailto:c...@apache.org>> wrote:
> 
>> Authenticated bind example:
>> 
>> 
>> 
>> $ ldapsearch -H ldaps://idmtest1-ec2-va.apache.org:636 -W -b
>> "dc=apache,dc=org" -L -D "uid=cml,ou=people,dc=apache,dc=org" uid=cml
>> Enter LDAP Password:
>> version: 1
>> 
>> #
>> # LDAPv3
>> # base  with scope subtree
>> # filter: uid=cml
>> # requesting: ALL
>> #
>> 
>> # cml, people, apache.org
>> dn: uid=cml,ou=people,dc=apache,dc=org
>> [snip]
>> 
>> 
>> 
> Does not work for me on the whimsy host:
> 
> 
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 
> 
> Nor on my macOS system:
> 
> No such object (32)
> 
> (Yes, I did change the bind details)
> 
> If I enter an incorrect password on macOS, I get:
> 
> ldap_bind: Invalid credentials (49)
> 
> This shows the server has been contacted at least.
> However using a bad password on Whimsy makes no difference.
> 
> Any tooling relying on UN-authenticated bind will need to switch to using a
>> role account. We're starting a process of locating and adjusting any of
>> these use cases. There are also a number of cases where tools like
>> 'ldapsearch' will use the nss_ldap bind account which is defined in
>> /etc/ldap/ldap.conf, so sometimes it appears the tools work without
>> passwords, but they are actually using the ldap.conf credentials.
>> 
>> -Chris
>> 
>> 
>> 
>> 
>>> On Oct 6, 2021, at 7:40 PM, Matt Sicker  wrote:
>>> 
>>> What authentication methods are supported now? I remember being unable
>> to find an incantation of ldapsearch that could authenticate.
>>> 
>>> Matt Sicker
>>> 
>>>> On Oct 6, 2021, at 18:40, Chris Lambertus  wrote:
>>>> 
>>>> Hi folks, just to let you know, my primary testing and implementation
>> of replication between idmtest1-ec2-va and idmtest2-ec2-va is complete. The
>> next stage in testing may be more disruptive -- the slapd.conf ACLs have
>> been changed to prevent unauthenticated access to the LDAP directory.
>>>> 
>>>> If your project has the capability to test, I would be interested to
>> know if Whimsy still functions properly with these security and privacy
>> enhancements in place. There will be a more broad discussion on this topic
>> brought to Infra lists once initial validation is complete.
>>>> 
>>>> Cheers,
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>>> On Sep 29, 2021, at 11:15 AM, Chris Lambertus  wrote:
>>>>> 
>>>>> FYI,
>>>>> 
>>>>> In https://issues.apache.org/jira/browse/INFRA-22091 <
>> https://issues.apache.org/jira/browse/INFRA-22091> a test ldap instance
>> was provided to the Whimsy project. This is a notification that Infra will
>> be performing work on that host over the next few days. The system may be
>> down and data may be unavailable during various operations. I will reply
>> here when work is completed. You may continue using the service, but you
>> may get timeouts or null results.
>>>>> 
>>>>> -Chris

Re: test LDAP instance downtime/updates

[Chris Lambertus]

Authenticated bind example:



$ ldapsearch -H ldaps://idmtest1-ec2-va.apache.org:636 -W -b "dc=apache,dc=org" 
-L -D "uid=cml,ou=people,dc=apache,dc=org" uid=cml
Enter LDAP Password:
version: 1

#
# LDAPv3
# base  with scope subtree
# filter: uid=cml
# requesting: ALL
#

# cml, people, apache.org
dn: uid=cml,ou=people,dc=apache,dc=org
[snip]


Any tooling relying on UN-authenticated bind will need to switch to using a 
role account. We're starting a process of locating and adjusting any of these 
use cases. There are also a number of cases where tools like 'ldapsearch' will 
use the nss_ldap bind account which is defined in /etc/ldap/ldap.conf, so 
sometimes it appears the tools work without passwords, but they are actually 
using the ldap.conf credentials.

-Chris




> On Oct 6, 2021, at 7:40 PM, Matt Sicker  wrote:
> 
> What authentication methods are supported now? I remember being unable to 
> find an incantation of ldapsearch that could authenticate.
> 
> Matt Sicker
> 
>> On Oct 6, 2021, at 18:40, Chris Lambertus  wrote:
>> 
>> Hi folks, just to let you know, my primary testing and implementation of 
>> replication between idmtest1-ec2-va and idmtest2-ec2-va is complete. The 
>> next stage in testing may be more disruptive -- the slapd.conf ACLs have 
>> been changed to prevent unauthenticated access to the LDAP directory.
>> 
>> If your project has the capability to test, I would be interested to know if 
>> Whimsy still functions properly with these security and privacy enhancements 
>> in place. There will be a more broad discussion on this topic brought to 
>> Infra lists once initial validation is complete.
>> 
>> Cheers,
>> Chris
>> 
>> 
>> 
>>> On Sep 29, 2021, at 11:15 AM, Chris Lambertus  wrote:
>>> 
>>> FYI,
>>> 
>>> In https://issues.apache.org/jira/browse/INFRA-22091 
>>> <https://issues.apache.org/jira/browse/INFRA-22091> a test ldap instance 
>>> was provided to the Whimsy project. This is a notification that Infra will 
>>> be performing work on that host over the next few days. The system may be 
>>> down and data may be unavailable during various operations. I will reply 
>>> here when work is completed. You may continue using the service, but you 
>>> may get timeouts or null results. 
>>> 
>>> -Chris
>>> 
>> 

Re: test LDAP instance downtime/updates

[Chris Lambertus]

Hi folks, just to let you know, my primary testing and implementation of 
replication between idmtest1-ec2-va and idmtest2-ec2-va is complete. The next 
stage in testing may be more disruptive -- the slapd.conf ACLs have been 
changed to prevent unauthenticated access to the LDAP directory.

If your project has the capability to test, I would be interested to know if 
Whimsy still functions properly with these security and privacy enhancements in 
place. There will be a more broad discussion on this topic brought to Infra 
lists once initial validation is complete.

Cheers,
Chris



> On Sep 29, 2021, at 11:15 AM, Chris Lambertus  wrote:
> 
> FYI,
> 
> In https://issues.apache.org/jira/browse/INFRA-22091 
> <https://issues.apache.org/jira/browse/INFRA-22091> a test ldap instance was 
> provided to the Whimsy project. This is a notification that Infra will be 
> performing work on that host over the next few days. The system may be down 
> and data may be unavailable during various operations. I will reply here when 
> work is completed. You may continue using the service, but you may get 
> timeouts or null results. 
> 
> -Chris
> 

test LDAP instance downtime/updates

[Chris Lambertus]

FYI,

In https://issues.apache.org/jira/browse/INFRA-22091 
 a test ldap instance was 
provided to the Whimsy project. This is a notification that Infra will be 
performing work on that host over the next few days. The system may be down and 
data may be unavailable during various operations. I will reply here when work 
is completed. You may continue using the service, but you may get timeouts or 
null results. 

-Chris

[jira] [Commented] (WHIMSY-351) https://whimsy.apache.org/roster tool very slow

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17394830#comment-17394830
 ] 

Chris Lambertus commented on WHIMSY-351:


As far as I can tell, this does indeed appear to be working as expected now. 
Thanks!

> https://whimsy.apache.org/roster tool very slow
> ---
>
> Key: WHIMSY-351
> URL: https://issues.apache.org/jira/browse/WHIMSY-351
> Project: Whimsy
>  Issue Type: Bug
>    Reporter: Chris Lambertus
>Priority: Minor
>
> Trying to access [https://whimsy.apache.org/roster] often times out, or is 
> very slow.  whimsy.a.o works fine, as does accessing rosters directly.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376916#comment-17376916
 ] 

Chris Lambertus commented on WHIMSY-113:


I know the topic has come up before, but I can't find a Jira ticket. Could one 
of you please create an Infra Jira for test ldap for Whimsy and I'll take care 
of setting up the instance. I already have one in progress as part of my ldap 
upgrade project.

 

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376911#comment-17376911
 ] 

Chris Lambertus commented on WHIMSY-113:


I've gone ahead and updated the apmail cron to run the dotqmail script every 5 
minutes. I feel this is quite sufficient for new account requests as long as 
the account creation tool uses the user's mail attribute rather than their 
@apache.org email address to send out the initial invite. 

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376908#comment-17376908
 ] 

Chris Lambertus commented on WHIMSY-113:


It looks like generate-dotqmail-availid.py only takes a few seconds to run, so 
we could easily run this every minute or two. I don't see any obvious locking 
in the script, so it would be best to avoid situations where it could be run 
simultaneously. I don't know of any situations where it would take considerably 
longer to run unless all 7k+ committers changed their forwarding addresses at 
the same time.

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376905#comment-17376905
 ] 

Chris Lambertus commented on WHIMSY-113:


I'm sure we can come up with an acceptable solution. We might just be able to 
run the dotqmail script more often, I'll take a look and see how long it takes 
to run.

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376900#comment-17376900
 ] 

Chris Lambertus commented on WHIMSY-113:


It would be better to use ssh whimsy apmail karma (which I believe exists? if 
not, it can be set up) to establish an initial .qmail file if desired. An alias 
that automatically runs the dotqmail script could be easily spammed/abused and 
potentially block or cause other issues if multiple instances of dotqmail are 
running simultaneously (I haven't checked if there is any kind of locking.) 
Infra would prefer ssh be used over an email alias as described.

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376899#comment-17376899
 ] 

Chris Lambertus commented on WHIMSY-113:


A * in the shadow field is the most common unix 'invalid password' string, but 
creating a random string is likely more portable. 

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376883#comment-17376883
 ] 

Chris Lambertus commented on WHIMSY-113:


Regarding karma for an account creation script, I don't know that such a thing 
would be needed. I would have to double check, but I believe adding the account 
to LDAP is the only requirement, as hermes creates the qmail forwarding files 
automatically, and there is no need to create a home dir anywhere else. 

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376881#comment-17376881
 ] 

Chris Lambertus commented on WHIMSY-113:


I can provide a test LDAP instance. 

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-351) https://whimsy.apache.org/roster tool very slow

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300727#comment-17300727
 ] 

Chris Lambertus commented on WHIMSY-351:


Not talking about github. Talking about [https://whimsy.apache.org/roster]. It 
is "fast" now, suddenly, after weeks of slowness and timeouts. I wonder if 
there's some whimsy job that locks this thread?

> https://whimsy.apache.org/roster tool very slow
> ---
>
> Key: WHIMSY-351
> URL: https://issues.apache.org/jira/browse/WHIMSY-351
> Project: Whimsy
>  Issue Type: Bug
>Reporter: Chris Lambertus
>Priority: Minor
>
> Trying to access [https://whimsy.apache.org/roster] often times out, or is 
> very slow.  whimsy.a.o works fine, as does accessing rosters directly.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (WHIMSY-351) https://whimsy.apache.org/roster tool very slow

[Chris Lambertus (Jira)]

Chris Lambertus created WHIMSY-351:
--

 Summary: https://whimsy.apache.org/roster tool very slow
 Key: WHIMSY-351
 URL: https://issues.apache.org/jira/browse/WHIMSY-351
 Project: Whimsy
  Issue Type: Bug
Reporter: Chris Lambertus


Trying to access [https://whimsy.apache.org/roster] often times out, or is very 
slow.  whimsy.a.o works fine, as does accessing rosters directly.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: whimsy.a.o: Password disclosure, information disclosure, file creation

[Chris Lambertus]

All,

I have not heard from anyone in the last hour, so I have shut down the Whimsy 
VM out of an abundance of caution until this issue can be assessed. I have 
verified at least one of the reports as legitimate (#3) however, all of these 
vectors -appear- to require authenticated access. I’m not able to vet the Ruby 
code so I can’t say for sure if there are vectors for non-authenticated users.

Any infra staffer can restart the whimsy-vm4 VM as needed once the situation is 
addressed.

-Chris




> On May 5, 2020, at 8:35 PM, Chris Lambertus  wrote:
> 
> Whimsy project, please respond to root@ and security@ ASAP with your 
> assessment. The issues described by Daniel are quite serious, and may warrant 
> shutting down the system until the problems are addressed.
> 
> 
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: Daniel Shahaf > <mailto:d...@daniel.shahaf.name>>
>> Subject: whimsy.a.o: Password disclosure, information disclosure, file 
>> creation
>> Date: May 5, 2020 at 1:36:22 PM PDT
>> To: r...@apache.org <mailto:r...@apache.org>
>> Cc: secur...@apache.org <mailto:secur...@apache.org>
>> 
>> [Cc'ing security@ because whimsy's technically a PMC]
>> 
>> ---
>> 
>> #1
>> 
>> https://whimsy.apache.org/committers/svn-info.cgi?url=svn%3A%2F%2Ffoo.example.org%2F
>>  
>> <https://whimsy.apache.org/committers/svn-info.cgi?url=svn%3A%2F%2Ffoo.example.org%2F>
>> 
>> If you click this URL now, you'll just get an HTML page that tells you
>> svn had failed with SVN_ERR_RA_CANNOT_CREATE_SESSION + ECONNREFUSED.
>> However, if I'd used a real URL in the query string and gotten some
>> committer to access the above link authenticatedly, they'd have accessed
>> a repository under my control with their LDAP credentials.  This enables
>> a password guessing attack.  I suspect that it also enables a password
>> leakage attack (i.e., that it'll happily send the password to the server
>> in cleartext, if the server offers no fancier authn methods) but haven't
>> verified this.
>> 
>> The remote URL doesn't have to be an apache.org one.  Even if it is,
>> anyone with a shell account on a PMC VM can bypass that.  Should
>> whitelist to 
>> r'^https?://(?:svn|dist)\.apache\.org(?::443)?/repos/(?:asf|private|…)/',
>> or better yet, use radio buttons to choose a repository and prompt for
>> the in-repository path only.
>> 
>> However, I'd sooner recommend to retire the page entirely.  The best way
>> for a CGI to use a user's password on their behalf is not to do it at all.
>> 
>> ---
>> 
>> #2
>> 
>> https://whimsy.apache.org/committers/svn-info.cgi?url=/x1/srv/whimsy/www/committers
>> 
>> There's no reason for this to work.  This may be an information
>> disclosure vector — not only directly via the output when it succeeds,
>> but also via whether the error is SVN_ERR_WC_NOT_WORKING_COPY (baseline)
>> or EACCES (meaning the argument exists and is chmod'd).
>> 
>> ---
>> 
>> #3
>> 
>> https://whimsy.apache.org/committers/svn-info.cgi?url=--config-dir=/tmp/bobby
>> 
>> Unconfirmed because I locked myself out of my account by accident, but
>> if it works, it'd be a vulnerability whereby any committer can create
>> directories anywhere on the VM with the permissions of the CGI script
>> user.  Then it can be used to DoS anything that relies on predictable
>> filenames (probably including several other whimsy apps).
>> 
>> It actually does escape the '=' sign, but I think that's not enough:
>> «sh -c 'echo foo\=bar'» prints «foo=bar».
>> 
>> ---
>> 
>> The good news is that it escapes spaces.  If it didn't, there'd be an
>> arbitrary code execution vulnerability.
>> 
>> You should probably double check that it escapes newlines, though.  (And
>> ampersands and pipes.  I checked semicolons.)
>> 
>> Daniel
> 

Fwd: whimsy.a.o: Password disclosure, information disclosure, file creation

[Chris Lambertus]

Whimsy project, please respond to root@ and security@ ASAP with your 
assessment. The issues described by Daniel are quite serious, and may warrant 
shutting down the system until the problems are addressed.





> Begin forwarded message:
> 
> From: Daniel Shahaf 
> Subject: whimsy.a.o: Password disclosure, information disclosure, file 
> creation
> Date: May 5, 2020 at 1:36:22 PM PDT
> To: r...@apache.org
> Cc: secur...@apache.org
> 
> [Cc'ing security@ because whimsy's technically a PMC]
> 
> ---
> 
> #1
> 
> https://whimsy.apache.org/committers/svn-info.cgi?url=svn%3A%2F%2Ffoo.example.org%2F
> 
> If you click this URL now, you'll just get an HTML page that tells you
> svn had failed with SVN_ERR_RA_CANNOT_CREATE_SESSION + ECONNREFUSED.
> However, if I'd used a real URL in the query string and gotten some
> committer to access the above link authenticatedly, they'd have accessed
> a repository under my control with their LDAP credentials.  This enables
> a password guessing attack.  I suspect that it also enables a password
> leakage attack (i.e., that it'll happily send the password to the server
> in cleartext, if the server offers no fancier authn methods) but haven't
> verified this.
> 
> The remote URL doesn't have to be an apache.org one.  Even if it is,
> anyone with a shell account on a PMC VM can bypass that.  Should
> whitelist to 
> r'^https?://(?:svn|dist)\.apache\.org(?::443)?/repos/(?:asf|private|…)/',
> or better yet, use radio buttons to choose a repository and prompt for
> the in-repository path only.
> 
> However, I'd sooner recommend to retire the page entirely.  The best way
> for a CGI to use a user's password on their behalf is not to do it at all.
> 
> ---
> 
> #2
> 
> https://whimsy.apache.org/committers/svn-info.cgi?url=/x1/srv/whimsy/www/committers
> 
> There's no reason for this to work.  This may be an information
> disclosure vector — not only directly via the output when it succeeds,
> but also via whether the error is SVN_ERR_WC_NOT_WORKING_COPY (baseline)
> or EACCES (meaning the argument exists and is chmod'd).
> 
> ---
> 
> #3
> 
> https://whimsy.apache.org/committers/svn-info.cgi?url=--config-dir=/tmp/bobby
> 
> Unconfirmed because I locked myself out of my account by accident, but
> if it works, it'd be a vulnerability whereby any committer can create
> directories anywhere on the VM with the permissions of the CGI script
> user.  Then it can be used to DoS anything that relies on predictable
> filenames (probably including several other whimsy apps).
> 
> It actually does escape the '=' sign, but I think that's not enough:
> «sh -c 'echo foo\=bar'» prints «foo=bar».
> 
> ---
> 
> The good news is that it escapes spaces.  If it didn't, there'd be an
> arbitrary code execution vulnerability.
> 
> You should probably double check that it escapes newlines, though.  (And
> ampersands and pipes.  I checked semicolons.)
> 
> Daniel

[jira] [Created] (WHIMSY-317) mirror_check.cgi broken

[Chris Lambertus (Jira)]

Chris Lambertus created WHIMSY-317:
--

 Summary: mirror_check.cgi broken
 Key: WHIMSY-317
 URL: https://issues.apache.org/jira/browse/WHIMSY-317
 Project: Whimsy
  Issue Type: Task
Reporter: Chris Lambertus


[https://whimsy.apache.org/members/mirror_check.cgi] is broken. It reports

# 
/x1/srv/whimsy/tools/mirror_check.rb:184:in `parseIndexPage' 
/x1/srv/whimsy/tools/mirror_check.rb:310:in `setup' 
/x1/srv/whimsy/tools/mirror_check.rb:231:in `checkHTTP' 
/x1/srv/whimsy/tools/mirror_check.rb:363:in `doPost' 
/x1/srv/whimsy/www/members/mirror_check.cgi:49:in `block (4 levels) in ' 
/x1/srv/whimsy/www/members/mirror_check.cgi:47:in `block (3 levels) in ' 
/x1/srv/whimsy/lib/whimsy/asf/themes.rb:195:in `block (3 levels) in 
_whimsy_body' /x1/srv/whimsy/lib/whimsy/asf/themes.rb:179:in `block (2 levels) 
in _whimsy_body' /x1/srv/whimsy/lib/whimsy/asf/themes.rb:178:in `block in 
_whimsy_body' /x1/srv/whimsy/lib/whimsy/asf/themes.rb:135:in `_whimsy_body' 
/x1/srv/whimsy/www/members/mirror_check.cgi:11:in `block (2 levels) in ' 
/x1/srv/whimsy/www/members/mirror_check.cgi:10:in `block in '



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Error 500 on user details - see INFRA-19803

[Chris Lambertus]

> On Feb 1, 2020, at 5:25 AM, Sam Ruby  wrote:
> 
> On Fri, Jan 31, 2020 at 11:18 PM Chris Lambertus  <mailto:c...@apache.org>> wrote:
>> 
>>> On Jan 31, 2020, at 6:49 PM, Shane Curcuru  wrote:
>>> 
>>> Sam Ruby wrote on 2020-1-31 9:43PM EST:
>>>> I've stubbed out the broken code:
>>>> 
>>>> https://github.com/apache/whimsy/commit/0b8be7daf678465c0d856fdd2fedf2b30d2a0331
>>>>  
>>>> <https://github.com/apache/whimsy/commit/0b8be7daf678465c0d856fdd2fedf2b30d2a0331>
>>> 
>>> Ah-ha! I was chatting with a might infra staffer about this, and was
>>> mystified that they fixed it immediately!  But it was actually Sam.
>>> 
>>> Opened a JIRA so we can plan what todo not on a Friday night, see a
>>> recent infra change made related:
>>> 
>>> https://issues.apache.org/jira/browse/INFRA-19803 
>>> <https://issues.apache.org/jira/browse/INFRA-19803>
>> 
>> See my comment on that ticket, and the related deprecation notice for the 
>> puppet3 code here:
>> 
>> https://lists.apache.org/thread.html/8a4776133a3269a8101c2cb64f6a474b153d2be3fb77c5800762%40
>>  
>> <https://lists.apache.org/thread.html/8a4776133a3269a8101c2cb64f6a474b153d2be3fb77c5800762@%3Cprivate.infra.apache.org%3E>
>> 
>> Please let infra know how we can assist you in setting up a cronjob on 
>> svn01-us-east so you can extract the data from the post-processed target 
>> system instead of the configuration management template.
> 
> 
> The post-processed data will have data from LDAP merged in, perhaps
> making it harder to determine what is uniquely defined in the
> authorization files and what is redundant and overlaps with data from
> other sources.


The puppet-based configuration management source files are deployed to the SVN 
host by puppet, and the cronjob which runs on the SVN host generates the auth 
file from those source templates. The same data is available in 
/x1/svn/authorization/templates as is available in puppet. My use of the term 
“post-processed” confused this issue, apologies. I meant to indicate 
post-puppet deployment. 
/x1/svn/authorization/templates/asf-authorization-template (and 
pit-authorization-template) exist on svn01-us-east in the same state that they 
exist in puppet. Whimsy simply needs to set up a cron job similar to hermes to 
acquire these templates directly from the SVN host rather than use a puppet 
checkout. I don’t see the templates changing format anytime soon.

Is this sufficient? Are there any concerns with using the templates as deployed 
on svn01-us-east?


-C





> 
> - Sam Ruby
> 
>> -Chris
>> 
>> 
>> 
>>> 
>>>> - Sam Ruby
>>>> 
>>>> On Fri, Jan 31, 2020 at 9:06 PM Craig Russell  wrote:
>>>>> 
>>>>> https://whimsy.apache.org/roster/committer/clr
>>>>> 
>>>>> "Hey, Rocky! Watch me pull a rabbit out of my hat."
>>>>> 
>>>>> Oh, snap! Something went wrong. Error details follow:
>>>>> 
>>>>>   • sinatra.error = No such file or directory @ rb_sysopen - 
>>>>> /x1/srv/git/infrastructure-puppet/modules/subversion_server/files/authorization/asf-authorization-template
>>>>>   • sinatra.route = GET /committer/:name
>>>>>   • REQUEST_URI = /roster/committer/clr
>>>>> ASF Members may also review access protected: /members/log/
>>>>> 
>>>>> Also please check for ASF system errors at: status.apache.org
>>>>> 
>>>>> There are errors in the members/log.
>>>>> 
>>>>> 
>>>>> Craig L Russell
>>>>> c...@apache.org
>>>>> 
>>> 
>>> 
>>> --
>>> 
>>> - Shane
>>> Whimsy PMC
>>> The Apache Software Foundation

Re: Error 500 on user details - see INFRA-19803

[Chris Lambertus]

> On Jan 31, 2020, at 6:49 PM, Shane Curcuru  wrote:
> 
> Sam Ruby wrote on 2020-1-31 9:43PM EST:
>> I've stubbed out the broken code:
>> 
>> https://github.com/apache/whimsy/commit/0b8be7daf678465c0d856fdd2fedf2b30d2a0331
>>  
>> 
> 
> Ah-ha! I was chatting with a might infra staffer about this, and was
> mystified that they fixed it immediately!  But it was actually Sam.
> 
> Opened a JIRA so we can plan what todo not on a Friday night, see a
> recent infra change made related:
> 
>  https://issues.apache.org/jira/browse/INFRA-19803 
> 

See my comment on that ticket, and the related deprecation notice for the 
puppet3 code here:

https://lists.apache.org/thread.html/8a4776133a3269a8101c2cb64f6a474b153d2be3fb77c5800762%40
 


Please let infra know how we can assist you in setting up a cronjob on 
svn01-us-east so you can extract the data from the post-processed target system 
instead of the configuration management template.

-Chris



> 
>> - Sam Ruby
>> 
>> On Fri, Jan 31, 2020 at 9:06 PM Craig Russell  wrote:
>>> 
>>> https://whimsy.apache.org/roster/committer/clr
>>> 
>>> "Hey, Rocky! Watch me pull a rabbit out of my hat."
>>> 
>>> Oh, snap! Something went wrong. Error details follow:
>>> 
>>>• sinatra.error = No such file or directory @ rb_sysopen - 
>>> /x1/srv/git/infrastructure-puppet/modules/subversion_server/files/authorization/asf-authorization-template
>>>• sinatra.route = GET /committer/:name
>>>• REQUEST_URI = /roster/committer/clr
>>> ASF Members may also review access protected: /members/log/
>>> 
>>> Also please check for ASF system errors at: status.apache.org
>>> 
>>> There are errors in the members/log.
>>> 
>>> 
>>> Craig L Russell
>>> c...@apache.org
>>> 
> 
> 
> -- 
> 
> - Shane
>  Whimsy PMC
>  The Apache Software Foundation

[jira] [Commented] (WHIMSY-298) create/maintain meta-groups for PMCs in LDAP

[Chris Lambertus (Jira)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965206#comment-16965206
 ] 

Chris Lambertus commented on WHIMSY-298:


It has not moved to p6 yet. We do not need or want the LDAP meta groups to have 
any control over any LDAP attributes. We are creating these meta groups so 
downstream technology that doesn't understand the owner/member attribute can 
function by creating specific "$project-pmc" LDAP groups that contain a list of 
PMC members ETLed from the owner attribute in the canonical group.

> create/maintain meta-groups for PMCs in LDAP
> 
>
> Key: WHIMSY-298
> URL: https://issues.apache.org/jira/browse/WHIMSY-298
> Project: Whimsy
>  Issue Type: New Feature
>Reporter: Chris Lambertus
>Priority: Minor
>
> Infra discovered a downside to the owner/member paradigm of the new LDAP 
> group management style, in that most commercial LDAP-based tooling doesn't 
> have the ability to set specific queries for various authentication 
> parameters. This is most notable in our Atlassian Crowd implementation, in 
> that Crowd only "sees" the members groups and has no way to parse out the 
> Owners for additional privilege scope. Infra has currently created a manual 
> workaround, which is documented in this (currently non-canonical, 
> non-functional) script:
> [https://github.com/apache/infrastructure-p6/blob/9813eacad87fcac69f21e7b7c3233541685bd789/modules/cwiki_asf/files/refresh_meta.sh]
>  
> As you can see, this script would create a new LDAP OU called 'meta' which 
> ETLs the existing owner attributes into a $project-pmc DN which is then 
> visible to Crowd and can be used to apply PMC permissions to Jira and 
> Confluence. We're currently doing this manually "on-demand" until we finish 
> some necessary back-end work for the script to function.
> I realize it's a step backwards to once again have to manage multiple LDAP 
> groups, but unfortunately, this separation is required due to a lack of 
> support for the owner/member attributes for Crowd. 
> It may be worth Whimsy considering patching to update both the ou=projects 
> and the PMC-based ou=meta groups. If this is something you'd like to do, I 
> would recommend a new OU, as Infra will be continuing to do this purge/ETL 
> for the ou=meta group for the foreseeable future.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (WHIMSY-298) create/maintain meta-groups for PMCs in LDAP

[Chris Lambertus (Jira)]

Chris Lambertus created WHIMSY-298:
--

 Summary: create/maintain meta-groups for PMCs in LDAP
 Key: WHIMSY-298
 URL: https://issues.apache.org/jira/browse/WHIMSY-298
 Project: Whimsy
  Issue Type: New Feature
Reporter: Chris Lambertus


Infra discovered a downside to the owner/member paradigm of the new LDAP group 
management style, in that most commercial LDAP-based tooling doesn't have the 
ability to set specific queries for various authentication parameters. This is 
most notable in our Atlassian Crowd implementation, in that Crowd only "sees" 
the members groups and has no way to parse out the Owners for additional 
privilege scope. Infra has currently created a manual workaround, which is 
documented in this (currently non-canonical, non-functional) script:

[https://github.com/apache/infrastructure-p6/blob/9813eacad87fcac69f21e7b7c3233541685bd789/modules/cwiki_asf/files/refresh_meta.sh]

 

As you can see, this script would create a new LDAP OU called 'meta' which ETLs 
the existing owner attributes into a $project-pmc DN which is then visible to 
Crowd and can be used to apply PMC permissions to Jira and Confluence. We're 
currently doing this manually "on-demand" until we finish some necessary 
back-end work for the script to function.

I realize it's a step backwards to once again have to manage multiple LDAP 
groups, but unfortunately, this separation is required due to a lack of support 
for the owner/member attributes for Crowd. 

It may be worth Whimsy considering patching to update both the ou=projects and 
the PMC-based ou=meta groups. If this is something you'd like to do, I would 
recommend a new OU, as Infra will be continuing to do this purge/ETL for the 
ou=meta group for the foreseeable future.

 

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (WHIMSY-279) mirror check tool requires Member access

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897440#comment-16897440
 ] 

Chris Lambertus commented on WHIMSY-279:


Thanks! It seems to be working just fine.

 

> mirror check tool requires Member access
> 
>
> Key: WHIMSY-279
> URL: https://issues.apache.org/jira/browse/WHIMSY-279
> Project: Whimsy
>  Issue Type: Bug
>    Reporter: Chris Lambertus
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The mirror checker tool at 
> [https://whimsy.apache.org/members/mirror_check.cgi] requires Member 
> authorization. Some Infra staffers are not Members. Could the auth on this 
> tool please be made to use infrastructure rather than Members?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (WHIMSY-279) mirror check tool requires Member access

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896489#comment-16896489
 ] 

Chris Lambertus commented on WHIMSY-279:


Infra's feeling is that the tool doesn't really need to be used by anyone 
outside of the 'infrastructure' LDAP group as referenced by Sam above. I do not 
have any strong preference either way, as long as non-Member infra staffers are 
able to use the tool. 

 

> mirror check tool requires Member access
> 
>
> Key: WHIMSY-279
> URL: https://issues.apache.org/jira/browse/WHIMSY-279
> Project: Whimsy
>  Issue Type: Bug
>Reporter: Chris Lambertus
>Priority: Major
>
> The mirror checker tool at 
> [https://whimsy.apache.org/members/mirror_check.cgi] requires Member 
> authorization. Some Infra staffers are not Members. Could the auth on this 
> tool please be made to use infrastructure rather than Members?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (WHIMSY-279) mirror check tool requires Member access

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896474#comment-16896474
 ] 

Chris Lambertus commented on WHIMSY-279:


This is blocking some infra staffers from using the tool.

 

> mirror check tool requires Member access
> 
>
> Key: WHIMSY-279
> URL: https://issues.apache.org/jira/browse/WHIMSY-279
> Project: Whimsy
>  Issue Type: Bug
>    Reporter: Chris Lambertus
>Priority: Major
>
> The mirror checker tool at 
> [https://whimsy.apache.org/members/mirror_check.cgi] requires Member 
> authorization. Some Infra staffers are not Members. Could the auth on this 
> tool please be made to use infrastructure rather than Members?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (WHIMSY-279) mirror check tool requires Member access

[Chris Lambertus (JIRA)]

Chris Lambertus created WHIMSY-279:
--

 Summary: mirror check tool requires Member access
 Key: WHIMSY-279
 URL: https://issues.apache.org/jira/browse/WHIMSY-279
 Project: Whimsy
  Issue Type: Bug
Reporter: Chris Lambertus


The mirror checker tool at [https://whimsy.apache.org/members/mirror_check.cgi] 
requires Member authorization. Some Infra staffers are not Members. Could the 
auth on this tool please be made to use infrastructure rather than Members?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (WHIMSY-270) non-PMC groups need to be treated as projects

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853740#comment-16853740
 ] 

Chris Lambertus commented on WHIMSY-270:


This is why I suggested the same workflow as PMCs which get the big blue 
"Create LDAP Groups" button. If the project wants them, we click the button. 
It's not really a matter of deciding who "qualifies" but whether or not they 
want/need the groups, so that in the future, the workflow is consistent, and 
they can gain access to all of the appropriate tooling that goes along with 
having ou=project groups.

 

> non-PMC groups need to be treated as projects
> -
>
> Key: WHIMSY-270
> URL: https://issues.apache.org/jira/browse/WHIMSY-270
> Project: Whimsy
>      Issue Type: New Feature
>Reporter: Chris Lambertus
>Priority: Major
>
> For groups such as D&I or others under 
> https://whimsy.apache.org/roster/nonpmc/ there should be the ability to 
> "press the button" to create and maintain the LDAP groups under ou=project. 
> This will provide the following benefits:
> - allow LDAP management of the nonPMC
> - allow self-service github repo creation
> - allow proper github authorization for repos
> I am not aware of any downsides for this approach. I have not reviewed the 
> code, but I am hoping it would be fairly trivial to implement, and would 
> quickly unblock INFRA-18453.
> The current state of affairs would require infra to manually create and 
> populate the LDAP group for D&I, which we'd prefer to avoid.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WHIMSY-270) non-PMC groups need to be treated as projects

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853723#comment-16853723
 ] 

Chris Lambertus commented on WHIMSY-270:


I agree [~sebb]. I am sure they chose ou=auth because it simply wasn't 
considered to make them a pseudo-project, or they predated the current 
owner/member LDAP tooling in whimsy. For all intents and purposes, I believe 
the entire project/pmc tooling workflow should be the same for non-PMCs, since 
it makes access to things like git and authentication workflow fit a standard 
model instead of being in an outlier ou=auth group.

I want to avoid conflating the issue of non-PMCs vs other entities in ou=auth. 
The majority (entirety?) of what's in ou=auth is svnauth for special cases. 
This does not need to change. The only thing that needs to change is that auth 
contexts for Projects (eg, the 10 listed in 
[https://whimsy.apache.org/roster/nonpmc/)] need to happen as ou=project 
groups. If a nonPMC project needs special case ou=auth outside of that, we 
should rename those entries to $project-purpose to not conflict with the 
ou=project ldap group name.

How are the 10 listed in the nonpmc roster differentiated from the other groups 
in ou=auth? Does that all come from cross-referencing of committee-info.txt?

 

> non-PMC groups need to be treated as projects
> -
>
> Key: WHIMSY-270
> URL: https://issues.apache.org/jira/browse/WHIMSY-270
> Project: Whimsy
>  Issue Type: New Feature
>Reporter: Chris Lambertus
>Priority: Major
>
> For groups such as D&I or others under 
> https://whimsy.apache.org/roster/nonpmc/ there should be the ability to 
> "press the button" to create and maintain the LDAP groups under ou=project. 
> This will provide the following benefits:
> - allow LDAP management of the nonPMC
> - allow self-service github repo creation
> - allow proper github authorization for repos
> I am not aware of any downsides for this approach. I have not reviewed the 
> code, but I am hoping it would be fairly trivial to implement, and would 
> quickly unblock INFRA-18453.
> The current state of affairs would require infra to manually create and 
> populate the LDAP group for D&I, which we'd prefer to avoid.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WHIMSY-270) non-PMC groups need to be treated as projects

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853542#comment-16853542
 ] 

Chris Lambertus commented on WHIMSY-270:


[~sebb] I don't see that adding ou=project groups for nonPMCs would materially 
change their workflows since they are not able to currently use github or 
self-service in any meaningful way without those groups. So, while I agree that 
they don't use LDAP in a consistent way, adding the ou=project groups for 
nonPMCs will not break anything, and will only serve to unify and simplify 
future management of these groups, and allow the nonPMC groups to use infra 
services in ways they were not previously able (while losing no previous 
functionality.)

 

> non-PMC groups need to be treated as projects
> -
>
> Key: WHIMSY-270
> URL: https://issues.apache.org/jira/browse/WHIMSY-270
> Project: Whimsy
>  Issue Type: New Feature
>Reporter: Chris Lambertus
>Priority: Major
>
> For groups such as D&I or others under 
> https://whimsy.apache.org/roster/nonpmc/ there should be the ability to 
> "press the button" to create and maintain the LDAP groups under ou=project. 
> This will provide the following benefits:
> - allow LDAP management of the nonPMC
> - allow self-service github repo creation
> - allow proper github authorization for repos
> I am not aware of any downsides for this approach. I have not reviewed the 
> code, but I am hoping it would be fairly trivial to implement, and would 
> quickly unblock INFRA-18453.
> The current state of affairs would require infra to manually create and 
> populate the LDAP group for D&I, which we'd prefer to avoid.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Moved] (WHIMSY-270) non-PMC groups need to be treated as projects

[Chris Lambertus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lambertus moved INFRA-18520 to WHIMSY-270:


INFRA-Members:   (was: [infrastructure-team])
  Component/s: (was: Whimsy)
   (was: LDAP)
 Workflow: jira  (was: INFRA Workflow)
  Key: WHIMSY-270  (was: INFRA-18520)
  Project: Whimsy  (was: Infrastructure)

> non-PMC groups need to be treated as projects
> -
>
> Key: WHIMSY-270
> URL: https://issues.apache.org/jira/browse/WHIMSY-270
> Project: Whimsy
>  Issue Type: New Feature
>    Reporter: Chris Lambertus
>Priority: Major
>
> For groups such as D&I or others under 
> https://whimsy.apache.org/roster/nonpmc/ there should be the ability to 
> "press the button" to create and maintain the LDAP groups under ou=project. 
> This will provide the following benefits:
> - allow LDAP management of the nonPMC
> - allow self-service github repo creation
> - allow proper github authorization for repos
> I am not aware of any downsides for this approach. I have not reviewed the 
> code, but I am hoping it would be fairly trivial to implement, and would 
> quickly unblock INFRA-18453.
> The current state of affairs would require infra to manually create and 
> populate the LDAP group for D&I, which we'd prefer to avoid.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Moving Whimsy to new host: hermes cronjob updates

[Chris Lambertus]

I would respectfully urge caution here, certainly not because of Dave, but in 
general: the whimsy server itself, along with the code which runs on it, has 
far more privileges to extract data from the Foundation than just about 
anything or anyone other than root@. Some of the data that Whimsy has access to 
is PII, and should be protected thusly. It may not be appropriate to rsync 
certain data sets to a personal computer, even a Member's, so please be 
cognizant of that when downloading data for testing/development purposes. 

-Chris




> On Apr 30, 2019, at 9:25 AM, Sam Ruby  wrote:
> 
> As you are an ASF member, file an infra JIRA to give you shell access
> to whimsy-vm4.  Then you can rsync this or any other directory
> whenever you want.  As this is a minor request, you might even be able
> to get this done by asking nicely on hipchat^h^h^h^h^h^h^hslack.
> 
> - Sam Ruby
> 
> On Tue, Apr 30, 2019 at 11:38 AM Dave Fisher  wrote:
>> 
>> Hi -
>> 
>> I need /srv/subscriptions to properly debug podling roster page changes.
>> 
>> How can I get a one time copy of /srv/subscriptions on my local and how big 
>> is it?
>> 
>> Regards,
>> Dave
>> 
>>> On Apr 30, 2019, at 6:30 AM, sebb  wrote:
>>> 
>>> On Tue, 30 Apr 2019 at 13:44, Sam Ruby  wrote:
 
 Just a perspective from the one who set up whimsy vm 1 though 4.  When
 I was setting up whimsy 3 and 4, I updated those scripts to send data
 to whimsy n-1 and n.  Once the setup was completed, I removed n-1 from
 the instructions.
>>> 
>>> Yes, though it's not how listmodsubs.sh is set up currently.
>>> [That can be fixed.]
>>> 
 The issue is one of timing.  If one copies over the contents of
 various directories, and then later updates the DNS, there may be
 missing updates.
>>> 
>>> There is only a single directory involved here:  /srv/subscriptions
>>> The scripts are run every hour, and the output replaces whatever was
>>> there before.
>>> So whilst the data might be stale immediately after DNS changeover, it
>>> will soon be updated.
>>> I don't think there is any data that can be permanently lost here.
>>> 
>>> However it does occur to me that it's possible that the rsync might
>>> fail to work initially on the new host.
>>> Probably best not to discover that first on DNS changeover...
>>> 
>>> So I propose now to ensure listmodsubs.sh uses the same approach as
>>> whimsy_qmail_ids.sh
>>> (and document the reasoning)
>>> 
 - Sam Ruby
 
 On Tue, Apr 30, 2019 at 8:12 AM sebb  wrote:
> 
> There are two cronjobs on hermes that copy data to whimsy:
> 
> listmodsubs.sh
> - copies data files to whimsy.apache.org:/srv/subscriptions/
> 
> whimsy_qmail_ids.sh
> - writes data to whimsy-vm4.apache.org:/srv/subscriptions/qmail.ids
> 
> It would be nice if there were no need to update these scripts when
> the Whimsy VM is updated.
> 
> I propose to update whimsy_qmail_ids.sh to use the generic address.
> Both scripts would then only send data to the current master server.
> 
> For testing the new server, one can just copy over the contents of
> /srv/subscriptions.
> 
> When DNS is flipped, hermes would start to update the new master.
> 
> Does that make sense?
> 
> S.
>> 

[jira] [Commented] (WHIMSY-113) Have Secretary create new accounts directly

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827801#comment-16827801
 ] 

Chris Lambertus commented on WHIMSY-113:


Pursuant to the discussion via secretary/private@infra/root@ regarding account 
renames today, Infra and Secretary would like to see this happen. Please let us 
know how we can help.

> Have Secretary create new accounts directly
> ---
>
> Key: WHIMSY-113
> URL: https://issues.apache.org/jira/browse/WHIMSY-113
> Project: Whimsy
>  Issue Type: New Feature
>  Components: SecMail
>Reporter: Sam Ruby
>Assignee: Sam Ruby
>Priority: Major
>
> See also: https://issues.apache.org/jira/browse/INFRA-14456
> Currently most new account requests are made by the secretary, with the 
> remainder by PMC chairs and ASF members.  These requests are made by whimsy 
> forms and result in a file created in svn that is processed, generally daily, 
> by infrastructure staff.
> The new process envisioned is that the secretary will create new accounts 
> directly; and that new account requests will be sent via email to secretary@ 
> and processed by the secretary workbench.  Generally, processing of such 
> requests should be at most a few mouse clicks, though an opportunity will be 
> provided to tweak such things a public names and to verify that a proper vote 
> link was provided.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: decom of project CNs in ou=groups

[Chris Lambertus]

> On Mar 10, 2019, at 10:26 AM, Chris Lambertus  wrote:
> 
> 
> 
>> On Mar 9, 2019, at 1:16 AM, sebb  wrote:
>> 
>> On Sat, 9 Mar 2019 at 02:44, Chris Lambertus  wrote:
>>> 
>>> Thank you for your work on this, Sebb. I need to go through the threads and 
>>> make sure all the ’t’s are dotted and all the ‘i’s crossed, but then I’ll 
>>> start the work to decom that OU.
>> 
>> It might be sensible to start by dropping one or two ou=pmc groups
>> (apart from TAC and security) and see if anything breaks or changes.
>> 
>> Maybe then empty the OU and leave it a little while before removing it 
>> entirely?
>> A missing OU may be handle differently from an empty one (if it can be 
>> empty).
> 
> 
> I agree. I will follow up on the tac and security groups as well.
> 
> -Chris
> 

The time has come.. This is now affecting crowd/confluence integration, so 
we've begun deleting the legacy groups as needed. I will begin a wholesale 
removal of the legacy groups today, omitting things like committers and 
members. Once these are all cleaned up, we will have a new set of problems to 
sort out, but that's a story for another email.

Thanks for everyone's feedback. If any issues come up, please contact me and/or 
open an infra jira.

Thanks!

-Chris



> 
> 
> 
> 
> 
> 
>> 
>> Just a thought.
>> 
>> If things do break, it's presumably possible to temporarily recreate
>> the missing items whilst things are fixed.
>> 
>>> -Chris
>>> 
>>> 
>>> 
>>> 
>>>> On Mar 8, 2019, at 3:28 AM, sebb  wrote:
>>>> 
>>>> Whimsy no longer references LDAP ou=pmc groups  (*)
>>>> 
>>>> I emailed the TAC chair (Gavin) about the TAC discrepancies, but I've
>>>> not heard what the final resolution is.
>>>> 
>>>> S.
>>>> (*) except in the script that does basic checks of (asf|pit)-authorization
>>>> Those files still use ou=pmc for TAC and Security, so the script has
>>>> to allow for it.
>>>> Removal will not affect the script.
>>>> 
>>>> On Wed, 30 Jan 2019 at 23:11, sebb  wrote:
>>>>> 
>>>>> Turned out to be not too hard to recreate public_ldap_committees.json
>>>>> from ou=projects with some help from committee-info.txt.
>>>>> The public_ldap_groups.json file can also be created with some data
>>>>> from ou=groups to supply the non-PMC groups.
>>>>> 
>>>>> This should allow external projects to continue working mostly correctly.
>>>>> However the JSON files cannot be used to determine membership of
>>>>> ou=pmc or ou=groups.
>>>>> This has long been the case for the guinea pigs.
>>>>> 
>>>>> The updated scripts should continue to work even when projects are
>>>>> deleted from ou=pmc and ou=groups.
>>>>> 
>>>>> However the rest of the Whimsy code has yet to be updated; that is
>>>>> looking much more complicated.
>>>>> 
>>>>> 
>>>>> On Wed, 30 Jan 2019 at 15:48, sebb  wrote:
>>>>>> 
>>>>>> It's looking to be quite complicated to maintain compatibility.
>>>>>> I think this is important because external projects may rely on the
>>>>>> generated JSON data files, and it may not be possible to fix all the
>>>>>> projects in time.
>>>>>> 
>>>>>> The change will affect two of the JSON files:
>>>>>> public_ldap_groups.json
>>>>>> public_ldap_committees.json
>>>>>> 
>>>>>> In both the above cases, the guineapig projects are added to the output.
>>>>>> This was done to maintain compatibility for external projects.
>>>>>> In theory all projects now become guineapigs.
>>>>>> However the ou=projects list includes lots of podlings as well.
>>>>>> 
>>>>>> One way to maintain compatibility would be to make all the existing
>>>>>> projects in groups/committees into guineapigs.
>>>>>> A bit messy, but it might work.
>>>>>> 
>>>>>> Longer term, external projects need to stop using ldap_committees, and
>>>>>> only use ldap_groups for whatever is left (e.g. member, committers)
>>>>>> This involves fixing phonebook and projects.a.o; there are probably 
>>

Re: Mail delivery issues in whimsy/workbench

[Chris Lambertus]

Hi all,

This should be working now. I received the test mail from Sam’s tool.

-Chris




> On Mar 18, 2019, at 7:16 PM, Sam Ruby  wrote:
> 
> Should have replied to all...
> 
> -- Forwarded message -
> From: Sam Ruby 
> Date: Mon, Mar 18, 2019 at 9:48 PM
> Subject: Re: Mail delivery issues in whimsy/workbench
> To: Whimsy dev 
> 
> 
> Confirmed.  One line test case (anybody on the infrastructure team can
> run this):
> 
> ssh whimsy4.apache.org /usr/local/bin/ruby2.4.1 /srv/whimsy/tools/testmail.rb
> 
> This program will echo back the mail that was sent so that you can see
> the headers.  The email will be sent to you at your primary email
> address, and the from address will be your apache.org address.
> 
> - Sam Ruby
> 
> P.S.  I wrote this tool years ago for exactly this reason.
> 
> 
> On Mon, Mar 18, 2019 at 8:43 PM Craig Russell  wrote:
>> 
>> Whimsy mail is not working. There are no bounce/fail messages.
>> 
>> Secretary workbench is officially down.
>> 
>> No documents will be processed until mail can be sent from whimsy.
>> 
>> Please help.
>> 
>> Craig
>> 
>>> On Mar 18, 2019, at 4:58 PM, Chris Lambertus  wrote:
>>> 
>>> If mail failed/bounced, it would bounce to the original sender address.
>>> 
>>> -Chris
>>> 
>>> 
>>> 
>>>> On Mar 18, 2019, at 3:28 PM, Craig Russell  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Whimsy could not deliver email after the reconfiguration(?) last week.
>>>> 
>>>> Was there supposed to be some notification when mail was not delivered?
>>>> 
>>>> Is the undelivered mail still hanging out somewhere?
>>>> 
>>>> It will be a major pain to reconstruct the mail that was sent and not 
>>>> delivered.
>>>> 
>>>> Any help anywhere?
>>>> 
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> c...@apache.org http://db.apache.org/jdo
>>>> 
>>> 
>> 
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
>> <http://db.apache.org/jdo>

Re: Mail delivery issues in whimsy/workbench

[Chris Lambertus]

If mail failed/bounced, it would bounce to the original sender address.

-Chris



> On Mar 18, 2019, at 3:28 PM, Craig Russell  wrote:
> 
> Hi,
> 
> Whimsy could not deliver email after the reconfiguration(?) last week.
> 
> Was there supposed to be some notification when mail was not delivered?
> 
> Is the undelivered mail still hanging out somewhere?
> 
> It will be a major pain to reconstruct the mail that was sent and not 
> delivered.
> 
> Any help anywhere?
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
> 

workflow surrounding podling LDAP creation

[Chris Lambertus]

Hi folks,

There are two non-automated processes related to podling creation right now on 
the Infra side. One is creating DNS. The other is creating the LDAP entries for 
the podling. The LDAP creation is simply a matter of pushing a button in 
Whimsy. Is there a way the latter could be better automated? I’m not sure we’re 
going to get to a point where we can automate the DNS without oversight (due to 
the substantial cost of an error/outage) but it seems like we could very easily 
automate the podling LDAP group creation.

I’m not sure who has whimsy karma necessary to press the Whimsy button. Perhaps 
someone involved in the podling onboarding process outside of Infra could 
already do this? Maybe we could make it pressable by Mentors?

Thoughts?

-Chris

Re: decom of project CNs in ou=groups

[Chris Lambertus]

> On Mar 9, 2019, at 1:16 AM, sebb  wrote:
> 
> On Sat, 9 Mar 2019 at 02:44, Chris Lambertus  wrote:
>> 
>> Thank you for your work on this, Sebb. I need to go through the threads and 
>> make sure all the ’t’s are dotted and all the ‘i’s crossed, but then I’ll 
>> start the work to decom that OU.
> 
> It might be sensible to start by dropping one or two ou=pmc groups
> (apart from TAC and security) and see if anything breaks or changes.
> 
> Maybe then empty the OU and leave it a little while before removing it 
> entirely?
> A missing OU may be handle differently from an empty one (if it can be empty).


I agree. I will follow up on the tac and security groups as well.

-Chris







> 
> Just a thought.
> 
> If things do break, it's presumably possible to temporarily recreate
> the missing items whilst things are fixed.
> 
>> -Chris
>> 
>> 
>> 
>> 
>>> On Mar 8, 2019, at 3:28 AM, sebb  wrote:
>>> 
>>> Whimsy no longer references LDAP ou=pmc groups  (*)
>>> 
>>> I emailed the TAC chair (Gavin) about the TAC discrepancies, but I've
>>> not heard what the final resolution is.
>>> 
>>> S.
>>> (*) except in the script that does basic checks of (asf|pit)-authorization
>>> Those files still use ou=pmc for TAC and Security, so the script has
>>> to allow for it.
>>> Removal will not affect the script.
>>> 
>>> On Wed, 30 Jan 2019 at 23:11, sebb  wrote:
>>>> 
>>>> Turned out to be not too hard to recreate public_ldap_committees.json
>>>> from ou=projects with some help from committee-info.txt.
>>>> The public_ldap_groups.json file can also be created with some data
>>>> from ou=groups to supply the non-PMC groups.
>>>> 
>>>> This should allow external projects to continue working mostly correctly.
>>>> However the JSON files cannot be used to determine membership of
>>>> ou=pmc or ou=groups.
>>>> This has long been the case for the guinea pigs.
>>>> 
>>>> The updated scripts should continue to work even when projects are
>>>> deleted from ou=pmc and ou=groups.
>>>> 
>>>> However the rest of the Whimsy code has yet to be updated; that is
>>>> looking much more complicated.
>>>> 
>>>> 
>>>> On Wed, 30 Jan 2019 at 15:48, sebb  wrote:
>>>>> 
>>>>> It's looking to be quite complicated to maintain compatibility.
>>>>> I think this is important because external projects may rely on the
>>>>> generated JSON data files, and it may not be possible to fix all the
>>>>> projects in time.
>>>>> 
>>>>> The change will affect two of the JSON files:
>>>>> public_ldap_groups.json
>>>>> public_ldap_committees.json
>>>>> 
>>>>> In both the above cases, the guineapig projects are added to the output.
>>>>> This was done to maintain compatibility for external projects.
>>>>> In theory all projects now become guineapigs.
>>>>> However the ou=projects list includes lots of podlings as well.
>>>>> 
>>>>> One way to maintain compatibility would be to make all the existing
>>>>> projects in groups/committees into guineapigs.
>>>>> A bit messy, but it might work.
>>>>> 
>>>>> Longer term, external projects need to stop using ldap_committees, and
>>>>> only use ldap_groups for whatever is left (e.g. member, committers)
>>>>> This involves fixing phonebook and projects.a.o; there are probably 
>>>>> others.
>>>>> 
>>>>> The cutover date of Feb 9th might be somewhat optimistic.
>>>>> 
>>>>> I think we need to find out if there are any other projects using the
>>>>> 2 above-mentioned Whimsy JSON files.
>>>>> 
>>>>> On Wed, 30 Jan 2019 at 13:15, sebb  wrote:
>>>>>> 
>>>>>> On Wed, 30 Jan 2019 at 11:36, sebb  wrote:
>>>>>>> 
>>>>>>> Note mixed private and public lists
>>>>>>> 
>>>>>>> On Wed, 30 Jan 2019 at 09:37, sebb  wrote:
>>>>>>>> 
>>>>>>>> On Wed, 30 Jan 2019 at 03:54, Chris Lambertus  wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sam, Whimsy Dev,
>>>>>>>>> 
>>>>>>>>> Some time ago we migrated projects to use the ou=groups,ou=project 
>>>>>>>>> format with owner and member attributes.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The time has come to delete the legacy CNs.
>>>>>>>> 
>>>>>>>> It might make sense to fix Whimsy ASAP and see if that causes any 
>>>>>>>> grief.
>>>>>>> 
>>>>>>> I have started looking at Whimsy.
>>>>>>> 
>>>>>>> It needs a bit of care as the Groups/Project code is closely related,
>>>>>>> and we need to keep the Groups for members and committers etc.
>>>>>>> 
>>>>>>> There are some other entries only in ou=groups:
>>>>>>> 
>>>>>>> apsite concom infra podlings
>>>>>>> 
>>>>>>> I think infra and podlings are not used and could be deleted?
>>>>>>> (podlings is empty anyway)
>>>>>>> 
>>>>>>> apsite probably ought to be in a different OU -- if it is to be kept
>>>>>>> It gives write access to /websites/production/www; maybe an existing
>>>>>>> group (member?) would do
>>>>>>> 
>>>>>>> Not sure about concom - maybe it should be ou=project?
>>>>>> 
>>>>>> INFRA-17782 - create concom ou=project.
>>>>>> 
>>>>>>> S.
>> 

Re: decom of project CNs in ou=groups

[Chris Lambertus]

Thank you for your work on this, Sebb. I need to go through the threads and 
make sure all the ’t’s are dotted and all the ‘i’s crossed, but then I’ll start 
the work to decom that OU.

-Chris




> On Mar 8, 2019, at 3:28 AM, sebb  wrote:
> 
> Whimsy no longer references LDAP ou=pmc groups  (*)
> 
> I emailed the TAC chair (Gavin) about the TAC discrepancies, but I've
> not heard what the final resolution is.
> 
> S.
> (*) except in the script that does basic checks of (asf|pit)-authorization
> Those files still use ou=pmc for TAC and Security, so the script has
> to allow for it.
> Removal will not affect the script.
> 
> On Wed, 30 Jan 2019 at 23:11, sebb  wrote:
>> 
>> Turned out to be not too hard to recreate public_ldap_committees.json
>> from ou=projects with some help from committee-info.txt.
>> The public_ldap_groups.json file can also be created with some data
>> from ou=groups to supply the non-PMC groups.
>> 
>> This should allow external projects to continue working mostly correctly.
>> However the JSON files cannot be used to determine membership of
>> ou=pmc or ou=groups.
>> This has long been the case for the guinea pigs.
>> 
>> The updated scripts should continue to work even when projects are
>> deleted from ou=pmc and ou=groups.
>> 
>> However the rest of the Whimsy code has yet to be updated; that is
>> looking much more complicated.
>> 
>> 
>> On Wed, 30 Jan 2019 at 15:48, sebb  wrote:
>>> 
>>> It's looking to be quite complicated to maintain compatibility.
>>> I think this is important because external projects may rely on the
>>> generated JSON data files, and it may not be possible to fix all the
>>> projects in time.
>>> 
>>> The change will affect two of the JSON files:
>>> public_ldap_groups.json
>>> public_ldap_committees.json
>>> 
>>> In both the above cases, the guineapig projects are added to the output.
>>> This was done to maintain compatibility for external projects.
>>> In theory all projects now become guineapigs.
>>> However the ou=projects list includes lots of podlings as well.
>>> 
>>> One way to maintain compatibility would be to make all the existing
>>> projects in groups/committees into guineapigs.
>>> A bit messy, but it might work.
>>> 
>>> Longer term, external projects need to stop using ldap_committees, and
>>> only use ldap_groups for whatever is left (e.g. member, committers)
>>> This involves fixing phonebook and projects.a.o; there are probably others.
>>> 
>>> The cutover date of Feb 9th might be somewhat optimistic.
>>> 
>>> I think we need to find out if there are any other projects using the
>>> 2 above-mentioned Whimsy JSON files.
>>> 
>>> On Wed, 30 Jan 2019 at 13:15, sebb  wrote:
>>>> 
>>>> On Wed, 30 Jan 2019 at 11:36, sebb  wrote:
>>>>> 
>>>>> Note mixed private and public lists
>>>>> 
>>>>> On Wed, 30 Jan 2019 at 09:37, sebb  wrote:
>>>>>> 
>>>>>> On Wed, 30 Jan 2019 at 03:54, Chris Lambertus  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Sam, Whimsy Dev,
>>>>>>> 
>>>>>>> Some time ago we migrated projects to use the ou=groups,ou=project 
>>>>>>> format with owner and member attributes.
>>>>>>> 
>>>>>>> 
>>>>>>> The time has come to delete the legacy CNs.
>>>>>> 
>>>>>> It might make sense to fix Whimsy ASAP and see if that causes any grief.
>>>>> 
>>>>> I have started looking at Whimsy.
>>>>> 
>>>>> It needs a bit of care as the Groups/Project code is closely related,
>>>>> and we need to keep the Groups for members and committers etc.
>>>>> 
>>>>> There are some other entries only in ou=groups:
>>>>> 
>>>>> apsite concom infra podlings
>>>>> 
>>>>> I think infra and podlings are not used and could be deleted?
>>>>> (podlings is empty anyway)
>>>>> 
>>>>> apsite probably ought to be in a different OU -- if it is to be kept
>>>>> It gives write access to /websites/production/www; maybe an existing
>>>>> group (member?) would do
>>>>> 
>>>>> Not sure about concom - maybe it should be ou=project?
>>>> 
>>>> INFRA-17782 - create concom ou=project.
>>>> 
>>>>> S.

decom of project CNs in ou=groups

[Chris Lambertus]

Sam, Whimsy Dev,

Some time ago we migrated projects to use the ou=groups,ou=project format with 
owner and member attributes.


The time has come to delete the legacy CNs. Sebb has outlined a potential issue 
with tac-pmc (INFRA-16188), but I’ve asked him for clarification as I’m not 
entirely clear on what the issue is. 

As far as I know, we have updated all the tooling necessary to remove both of 
the following:

The legacy PMC OU: 
ou=pmc,ou=committees,ou=groups,dc=apache,dc=org


and the legacy project OUs:

cn=activemq,ou=groups,dc=apache,dc=org
cn=airavata,ou=groups,dc=apache,dc=org

etc.


I’d like to schedule this deletion for 9 February 2019 at approximately 1400 
UTC. This will give some daylight hours for me to troubleshoot any issues, as 
well as being early enough in the day for our EU folks to help as well if 
anything comes up.


Does anyone have any knowledge of systems which might still break? The old 
groups are so far out of date that I’d expect any problems to have surfaced by 
now, but one can never be too sure ..

Thoughts on the deletion date and general availability?

Thanks,
Chris
ASF Infra

Re: ldap-eu-ro.apache.org timeouts

[Chris Lambertus]

> On Feb 23, 2018, at 1:51 PM, sebb  wrote:
> 
>> 
>> Whimsy is in a US EC2 AZ. It should be using ldap-us-ro with eu-ro as a
>> fallback.
> 
> It uses all the defined LDAP servers in turn.



CC: dev@whimsical


In the case of Whimsy, which writes to LDAP, it could be switched over to 
ldap-master.a.o. IIRC it currently uses the servers in /etc/ldap/ldap.conf. 
Sometime in the somewhat near future (month-scale,) the -ro- servers will be 
switched to read-only, with ldap-master being the write master. This has the 
main benefit of centralizing the LDAP access logging, which can’t otherwise 
(easily) be replicated between multi-masters. I do intend to provide a method 
in puppet which sets servers known to write to LDAP (id.a.o for example) to 
ldap-master in /etc/ldap/ldap.conf, so you could also wait for that change.

In the case of Whimsy, switching to ldap-master has the added benefit of 
keeping Whimsy’s LDAP traffic local to AWS EC2, as they are currently both in 
the same AZ.

The LDAP ACL changes will be announced ahead of time, of course, this is just a 
heads up that could give you some additional performance benefits as well as 
future-proofing if you’re inclined to implement.

-Chris



signature.asc
Description: Message signed with OpenPGP

LDAP

[Chris Lambertus]

Hi folks,

I know some of you run a local test instance of Whimsy. If you do so, please 
note that Infra is replacing all LDAP servers with geo CNAMEs ldap-us-ro and 
ldap-eu-ro. If you have an LDAP configuration that uses anything other than 
these two names, please update it ASAP to avoid loss of connectivity.

In the future, those two servers will be set “read-only” and a master server 
‘ldap-master’ will be provided for write access for tooling which needs it.

-Chris



signature.asc
Description: Message signed with OpenPGP

[jira] [Moved] (WHIMSY-154) Username display broken on whimsy.a.o

[Chris Lambertus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lambertus moved INFRA-15485 to WHIMSY-154:


INFRA-Members:   (was: [infrastructure-team])
  Description: 
[moving issue to Whimsy project]

https://whimsy.apache.org/roster/committer/aaron is HTTP 500, as are other 
username pages I check. The error I see is:

"Hey, Rocky! Watch me pull a rabbit out of my hat."

Oh, snap! Something went wrong. Error details follow:

sinatra.error = Unexpected section /home/apmail/lists/apachecon.com/announce 
sirdeath7... [ed: VERY LONG LIST OF EMAIL ADDRESSES]
sinatra.route = GET /committer/:name
REQUEST_URI = /roster/committer/aaron


  was:
https://whimsy.apache.org/roster/committer/aaron is HTTP 500, as are other 
username pages I check. The error I see is:

"Hey, Rocky! Watch me pull a rabbit out of my hat."

Oh, snap! Something went wrong. Error details follow:

sinatra.error = Unexpected section /home/apmail/lists/apachecon.com/announce 
sirdeath7... [ed: VERY LONG LIST OF EMAIL ADDRESSES]
sinatra.route = GET /committer/:name
REQUEST_URI = /roster/committer/aaron


  Component/s: (was: Whimsy)
 Workflow: jira  (was: INFRA Workflow)
  Key: WHIMSY-154  (was: INFRA-15485)
  Project: Whimsy  (was: Infrastructure)

> Username display broken on whimsy.a.o
> -
>
> Key: WHIMSY-154
> URL: https://issues.apache.org/jira/browse/WHIMSY-154
> Project: Whimsy
>  Issue Type: Bug
>Reporter: Jim Apple
>
> [moving issue to Whimsy project]
> https://whimsy.apache.org/roster/committer/aaron is HTTP 500, as are other 
> username pages I check. The error I see is:
> "Hey, Rocky! Watch me pull a rabbit out of my hat."
> Oh, snap! Something went wrong. Error details follow:
> sinatra.error = Unexpected section /home/apmail/lists/apachecon.com/announce 
> sirdeath7... [ed: VERY LONG LIST OF EMAIL ADDRESSES]
> sinatra.route = GET /committer/:name
> REQUEST_URI = /roster/committer/aaron



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WHIMSY-145) add redirect to mlreq page

[Chris Lambertus (JIRA)]

Chris Lambertus created WHIMSY-145:
--

 Summary: add redirect to mlreq page
 Key: WHIMSY-145
 URL: https://issues.apache.org/jira/browse/WHIMSY-145
 Project: Whimsy
  Issue Type: Improvement
Reporter: Chris Lambertus


Hi, https://selfserve.apache.org/mail.html has superseded the non-automated 
mlreq form. Could you please add a redirect on the whimsy mlreq and 
incubator/mlreq pages to the selfserve site? Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: LDAP title field

[Chris Lambertus]

> On Apr 9, 2017, at 5:22 PM, Craig Russell  wrote:
> 
> tl;dr Adding title field is fine. I see it as secretary's responsibility to 
> harmonize iclas.txt and ldap.

Ack.

> We might as well add Suffix to LDAP to cater for the 23 III and 6 II that we 
> have. I've added a comment to IIINFRA-13850

Agreed. Are there any other person-data related fields we should consider 
capturing/adding? Now’s the time, since I’m committed to updating the infra 
ldap/adduser tooling at this point.



>> On Apr 9, 2017, at 10:05 AM, Sam Ruby  wrote:



>> Once created, we need to nail down the responsibility for updating
>> names.  Given that names change infrequently and at least one copy
>> (iclas.txt) isn't updateable by users themselves, this responsibility
>> should go to the secretary (Craig, please confirm?), and the necessary
>> tooling needs to be in place to allow the secretarial team to do so.
> 
> Secretary is up to this task, given adequate tooling.

Excellent. I think this will be a good use for the existing LDAP/ICLA 
comparison tool, which could probably be extended to allow for some simple “on 
the fly” editing of the various fields to correct any discrepancies.

>> ---
>> 
>> The format of a new-account-request isn't flexible, but is workable
>> (I'd prefer JSON or YAML, but adding still more fields at the end is
>> probably easier):

I’m not opposed in theory, but grafting a JSON or YAML parser onto the existing 
ap-adduser code is out of scope right now, and more than likely not worth the 
effort. If we want to go down that road, it would make more sense to rewrite 
the acreq process from the ground up.



Thanks for the input so far. Technical/implementation details can be captured 
in INFRA-13850.

-Chris




signature.asc
Description: Message signed with OpenPGP

LDAP title field

[Chris Lambertus]

Hi Whimsy,

I’m proposing in https://issues.apache.org/jira/browse/INFRA-13850 
 that we implement the Title 
field in LDAP. This would require some tooling changes that would involve 
Secretary, possibly whimsy code, and infra mods to the ap-adduser scripts and 
other tools that manage and process new-account-reqs.txt.

Any thoughts on this change and what would need to be touched to make this 
happen?

-Chris



signature.asc
Description: Message signed with OpenPGP

Re: Bug in account creation process?

[Chris Lambertus]

I don’t have access to that URL. If you or Sam or whomever can grant it, I can 
investigate further.

Presuming you’re referring to the iclas.txt notinavailid issue, that wasn’t 
what I was specifically going to fix, but I mentioned it to Pono just now, and 
we’re looking into it. My fix involves updating the accounts in LDAP with a 
correct surname field where currently it is the uid. Copying private@infra so 
Pono can see the thread. Dunno if he’s on dev@whimsical.

-Chris



> On Apr 5, 2017, at 3:28 PM, Craig Russell  wrote:
> 
> Hi Chris,
> 
> If I understand your message, you are going to go through the list of 
> accounts in https://whimsy.apache.org/secretary/public-names 
> <https://whimsy.apache.org/secretary/public-names><https://whimsy.apache.org/secretary/public-names
>  <https://whimsy.apache.org/secretary/public-names>> that are marked as Only 
> in LDAP and synchronize that with iclas.txt.
> 
> Please confirm.
> 
> Regards,
> 
> Craig
> 
>> On Apr 4, 2017, at 7:58 PM, Chris Lambertus > <mailto:c...@apache.org>> wrote:
>> 
>> 
>>> On Apr 4, 2017, at 4:38 PM, sebb >> <mailto:seb...@gmail.com>> wrote:
>>> 
>>> There are some other issues with the sn field:
>> 
>> 
>> I don’t see any issues in your output. To improve LDAP tooling and 
>> functionality as we bring more LDAP-based services online, I fixed the 
>> ap-adduser script to add a valid givenName and sn to new accounts based on 
>> extracted values of $FULLNAME (cn.) This only affects accounts created after 
>> the script change. I’m in the process of verifying that there are no 
>> unexpected consequences, then will re-populate the remaining sn attributes 
>> for older accounts with their valid surname. Prior to my change, the script 
>> inserted the uid as the sn for unknown reasons.
>> 
>> I am aware of one case of a user with no apparent surname. The adduser 
>> changes will not affect old accounts. New accounts which arrive with a 
>> single name will be rejected and will need to be manually processed.
>> 
>> Users in LDAP with no valid surname will not have their sn field modified 
>> (i.e. they will remain $uid.)
>> 
>> -Chris
>> 
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org <mailto:c...@apache.org> <mailto:c...@apache.org 
> <mailto:c...@apache.org>> http://db.apache.org/jdo <http://db.apache.org/jdo> 
> <http://db.apache.org/jdo <http://db.apache.org/jdo>>



signature.asc
Description: Message signed with OpenPGP

Re: Bug in account creation process?

[Chris Lambertus]

> On Apr 4, 2017, at 4:38 PM, sebb  wrote:
> 
> There are some other issues with the sn field:


I don’t see any issues in your output. To improve LDAP tooling and 
functionality as we bring more LDAP-based services online, I fixed the 
ap-adduser script to add a valid givenName and sn to new accounts based on 
extracted values of $FULLNAME (cn.) This only affects accounts created after 
the script change. I’m in the process of verifying that there are no unexpected 
consequences, then will re-populate the remaining sn attributes for older 
accounts with their valid surname. Prior to my change, the script inserted the 
uid as the sn for unknown reasons.

I am aware of one case of a user with no apparent surname. The adduser changes 
will not affect old accounts. New accounts which arrive with a single name will 
be rejected and will need to be manually processed.

Users in LDAP with no valid surname will not have their sn field modified (i.e. 
they will remain $uid.)

-Chris



signature.asc
Description: Message signed with OpenPGP

[jira] [Commented] (WHIMSY-49) Does INFRA-7390 have implications for allowable user ids?

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201924#comment-15201924
 ] 

Chris Lambertus commented on WHIMSY-49:
---

It was assigned to whimsy due to a bit of a misunderstanding on my part and a 
comment from Sebb about making the secretary tool aware of this. Feel free to 
assign back to infra, we'll take a look at the relevant id.a.o code.

> Does INFRA-7390 have implications for allowable user ids?
> -
>
> Key: WHIMSY-49
> URL: https://issues.apache.org/jira/browse/WHIMSY-49
> Project: Whimsy
>  Issue Type: Task
>Reporter: Sebb
> Attachments: WHIMSY-49-2.patch, WHIMSY-49.patch
>
>
> INFRA-7390 introduced e-mail aliases of the form
> availid-suf...@apache.org
> Now there are already some availids which contain a hyphen "-".
> Currently the list is:
> an-selm
> james-masanz
> jean-louis
> rgb-es
> soc-xzw
> swaroop-aj
> To avoid ambiguity, this means that the following ids should not be issued
> an
> james
> jean
> rgb
> soc
> swaroop
> AFAICT, these ids have not yet been allocated.
> But if any such ids were issued, there would be opportunities for mails to be 
> unexpectedly misdirected.
> I don't know how potential availids are screened for suitability.
> If there is an automated check, it should be trivial to add the first part of 
> existing ids to the list of exclusions.
> Note that the suffix can contain hyphens, so an availid of the form "a-b-c" 
> should disallow "a-b" as well as "a", etc. for additional hyphens



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WHIMSY-51) can't remove pgp fingerprint from id.apache.org

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181841#comment-15181841
 ] 

Chris Lambertus commented on WHIMSY-51:
---

I think all of that is TBD. There's still desire to work with Syncope on a 
stronger IDM tool, and it seems to me that this would be part and parcel of an 
interoperation plan between whatever Syncope becomes and the usage of the 
roster/secretary tools for account creation/management. Id.a.o falls kind of in 
a grey area. In terms of future work and policy direction, perhaps [~ke4qqq] 
can weigh in. If the desire is to fix id.a.o then we should move this back to 
INFRA. That goes for any of the tickets I've assigned to whimsy, too. I'm not 
trying to create work for anyone, but I put a few tickets over here because 
they seem to line up with what the whimsy PMC is trying to do with that 
codebase.

> can't remove pgp fingerprint from id.apache.org
> ---
>
> Key: WHIMSY-51
> URL: https://issues.apache.org/jira/browse/WHIMSY-51
> Project: Whimsy
>  Issue Type: New Feature
>Reporter: Henk Penning
>
> It looks like I can't delete a pgp finger-print from id.apache.org.
> The application shows me three key-entry-boxes ; 1 real, 1 fake, 1 empty. I 
> want to the delete the 'fake'. If/when I empty the box with the fake-key, and 
> submit, I get an error saying that the submitted keys are not 'pairwise 
> distinct'. That is correct because two of them are empty.
> Methinks the test is wrong ; too strong. The submitted keys may be equal, if 
> they are both empty.
> Thanks for the fix :-).
> HPP



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Moved] (WHIMSY-52) Duplicate emails after git merge

[Chris Lambertus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lambertus moved INFRA-7 to WHIMSY-52:
---

INFRA-Members:   (was: [infrastructure-team])
  Component/s: (was: Git)
 Workflow: jira  (was: INFRA Workflow)
  Key: WHIMSY-52  (was: INFRA-7)
  Project: Whimsy  (was: Infrastructure)

> Duplicate emails after git merge
> 
>
> Key: WHIMSY-52
> URL: https://issues.apache.org/jira/browse/WHIMSY-52
> Project: Whimsy
>  Issue Type: Bug
>Reporter: Sam Ruby
>Priority: Minor
>
> Description of the problem:
> https://mail-archives.apache.org/mod_mbox/whimsical-dev/201601.mbox/%3CCAOGo0VaZw01Xs7+R7dZSjc4o3Td_X4tBSzi1o+Wh92B3=g9...@mail.gmail.com%3E
> The root cause appears to be that common git workflows produce new commits by 
> "replaying" deltas in other branches as a part of a merge; these new commits 
> are then considered distinct, and even flagged as such by the PushEvent 
> GitHub webhook:
> https://developer.github.com/v3/activity/events/types/#pushevent
> It might be worth exploring how other software projects deal with this 
> (and/or making use of existing hooks).  One such example:
> https://github.com/git-multimail/git-multimail/blob/master/git-multimail/git_multimail.py#L3077



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (WHIMSY-51) can't remove pgp fingerprint from id.apache.org

[Chris Lambertus (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15181565#comment-15181565
 ] 

Chris Lambertus commented on WHIMSY-51:
---

Kicking this over to the whimsy project. It's not something infra's going to 
address in what's currently on id.a.o


> can't remove pgp fingerprint from id.apache.org
> ---
>
> Key: WHIMSY-51
> URL: https://issues.apache.org/jira/browse/WHIMSY-51
> Project: Whimsy
>  Issue Type: New Feature
>Reporter: Henk Penning
>
> It looks like I can't delete a pgp finger-print from id.apache.org.
> The application shows me three key-entry-boxes ; 1 real, 1 fake, 1 empty. I 
> want to the delete the 'fake'. If/when I empty the box with the fake-key, and 
> submit, I get an error saying that the submitted keys are not 'pairwise 
> distinct'. That is correct because two of them are empty.
> Methinks the test is wrong ; too strong. The submitted keys may be equal, if 
> they are both empty.
> Thanks for the fix :-).
> HPP



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Moved] (WHIMSY-51) can't remove pgp fingerprint from id.apache.org

[Chris Lambertus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lambertus moved INFRA-10234 to WHIMSY-51:
---

  Security: (was: public)
  Workflow: jira  (was: INFRA Workflow)
Issue Type: New Feature  (was: Bug)
   Key: WHIMSY-51  (was: INFRA-10234)
   Project: Whimsy  (was: Infrastructure)

> can't remove pgp fingerprint from id.apache.org
> ---
>
> Key: WHIMSY-51
> URL: https://issues.apache.org/jira/browse/WHIMSY-51
> Project: Whimsy
>  Issue Type: New Feature
>Reporter: Henk Penning
>
> It looks like I can't delete a pgp finger-print from id.apache.org.
> The application shows me three key-entry-boxes ; 1 real, 1 fake, 1 empty. I 
> want to the delete the 'fake'. If/when I empty the box with the fake-key, and 
> submit, I get an error saying that the submitted keys are not 'pairwise 
> distinct'. That is correct because two of them are empty.
> Methinks the test is wrong ; too strong. The submitted keys may be equal, if 
> they are both empty.
> Thanks for the fix :-).
> HPP



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Moved] (WHIMSY-49) Does INFRA-7390 have implications for allowable user ids?

[Chris Lambertus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lambertus moved INFRA-8396 to WHIMSY-49:
--

Security: (was: public)
Workflow: jira  (was: INFRA Workflow)
 Key: WHIMSY-49  (was: INFRA-8396)
 Project: Whimsy  (was: Infrastructure)

> Does INFRA-7390 have implications for allowable user ids?
> -
>
> Key: WHIMSY-49
> URL: https://issues.apache.org/jira/browse/WHIMSY-49
> Project: Whimsy
>  Issue Type: Task
>Reporter: Sebb
>Assignee: Sam Ruby
>
> INFRA-7390 introduced e-mail aliases of the form
> availid-suf...@apache.org
> Now there are already some availids which contain a hyphen "-".
> Currently the list is:
> an-selm
> james-masanz
> jean-louis
> rgb-es
> soc-xzw
> swaroop-aj
> To avoid ambiguity, this means that the following ids should not be issued
> an
> james
> jean
> rgb
> soc
> swaroop
> AFAICT, these ids have not yet been allocated.
> But if any such ids were issued, there would be opportunities for mails to be 
> unexpectedly misdirected.
> I don't know how potential availids are screened for suitability.
> If there is an automated check, it should be trivial to add the first part of 
> existing ids to the list of exclusions.
> Note that the suffix can contain hyphens, so an availid of the form "a-b-c" 
> should disallow "a-b" as well as "a", etc. for additional hyphens



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Bug in new account page

[Chris Lambertus]

Can you try this again please? This may have been due to a transient issue with 
LDAP.

> On Jul 6, 2015, at 1:23 PM, Craig L Russell  wrote:
> 
> Hi,
> 
> The drop down for project is unresponsive when accessing the new account page 
> from within the secretary assistant tool. Or outside. If I press (submit) 
> anyway, there is a somewhat ambiguous error message “Unsafe PMC”.
> 
> https://id.apache.org/acreq/members/?email=dlaurance.dev%40gmail.com&user=dlaurance&pmc=incubator&podling=openaz&votelink=http%3A%2F%2Fwiki.apache.org%2Fincubator%2FOpenAZProposal
> 
> 
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:craig.russ...@oracle.com
> P.S. A good JDO? O, Gasp!
>