Project

General

Profile

Feature #3054

Add option to glidecondor_addDN to auto-extract cert DN

Added by Igor Sfiligoi almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Igor Sfiligoi
Category:
-
Target version:
Start date:
10/19/2012
Due date:
% Done:

0%

Estimated time:
Spent time:
Stakeholders:
Duration:

Description

For situations where we want to add the DN of a cert/proxy that is on the local disk,
having glidecondor_addDN automatically extract the DN from the file would be
both handy and would reduce human error.

History

#1 Updated by Igor Sfiligoi almost 7 years ago

  • Status changed from New to Feedback
  • Assignee changed from Igor Sfiligoi to Parag Mhashilkar

Feature implemented in
branch_v2plus_igor_3054

Please review.

#2 Updated by Parag Mhashilkar almost 7 years ago

  • Assignee changed from Parag Mhashilkar to Igor Sfiligoi

Comments below, rest look ok to me.
Any reason not to use strip() over [:-1] in line below? strip seems more safer to me

dn=p.communicate()[0][9:-1]

Maybe this is personal preference,

while dn.endswith('/CN=proxy')

seems more readable than

while dn[-9:]=='/CN=proxy':

#3 Updated by Igor Sfiligoi almost 7 years ago

Technically, trailing space are legal in a DN.

Stripping exactly one character (the newline), is safer in my view.

#4 Updated by Parag Mhashilkar almost 7 years ago

So what if a version of openssl starts spitting out dn without newline? The current code will break but if you use strip() you are covered. Also I dont know of anyone that does string matching of dn with trailing spaces. I would say it was not a good decision to allow trailing spaces in DN, but thats not upto me now.

#5 Updated by Igor Sfiligoi almost 7 years ago

If openssl changes the output format, all bets are off.

I still believe strict semantics is better.

#6 Updated by Burt Holzman almost 7 years ago

compromise: call strip('\n'). It will strip only the newline and not whitespace.

#7 Updated by Parag Mhashilkar almost 7 years ago

extract_DN() is broken for rfc proxies and needs to be fixed.

My test giving it rfc proxy returned
'subject= /DC=org/DC=doegrids/OU=People/CN=Parag Mhashilkar 209917/CN=381159416'

I remember vaguely fixing a issue something like this in the code elsewhere couple of years back. Just cant seem to recollect exactly where. Maybe we can just reuse that?

#8 Updated by Igor Sfiligoi almost 7 years ago

I thought the CN=XYZ were deprecated, but I jsut checked, and you are right...
the RFC ones indeed use that syntax :(

Will have to fix this, it seems.

However, the only reliable way is using the

voms-proxy-info -chain

command.

Should I assume it is available?

#9 Updated by Igor Sfiligoi almost 7 years ago

  • Assignee changed from Igor Sfiligoi to Parag Mhashilkar

I have implemented the extract_DN function using the M2Crypto library calls;
(should have done it from the start!)
It now properly climbs the chain, and extracts the first non-CA DN from the file.

I also converted all newline removal lines to use rstrip.

Parag: Can you please check if there are any remaining issues?

#10 Updated by Parag Mhashilkar almost 7 years ago

  • Assignee changed from Parag Mhashilkar to Igor Sfiligoi

Logic looks ok to merge. I haven't tried the output of the m2crypto apis and I am assuming you tested it.

#11 Updated by Igor Sfiligoi almost 7 years ago

  • Status changed from Feedback to Closed

Merged into both branch_v2plus and master.

#12 Updated by Parag Mhashilkar almost 7 years ago

  • Target version set to 293

#13 Updated by Parag Mhashilkar over 6 years ago

  • Target version changed from 293 to v2_7


Also available in: Atom PDF