[openssl.org #654] openssl.pc gets wrong permissions
openssl.pc is copied into place with no chmod. Why can't install -m644 be used? If you're already using unix centric cp, what's wrong with install? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #654] openssl.pc gets wrong permissions
Good catch, thanks. I added an appropriate chmod, which resolves this ticket. As for why we don't use install: it's currently more work than to just add a chmod, and we're not entirely sure it exists everywhere. I'll investigate when I have more time on my hands. [EMAIL PROTECTED] - Fri Jul 4 08:34:42 2003]: openssl.pc is copied into place with no chmod. Why can't install -m644 be used? If you're already using unix centric cp, what's wrong with install? mrc -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) groups is fine when a child function is adding a new error, however, what happends groups when it calls ERR_clear_error ? In my implementation I need the error stack groups to be preserved even if a child function calls ERR_clear_error. groups groups That's why if you happended to remove the if (!err_fns) test in groups ERR_set_implementation, I would be more than happy. I'm sorry, but in what way does that prevent the error stack to be cleared? Maybe a better thing would be to have a flag that inhibits clearing the error stack... I'll ponder over this issue. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #80] OIDs still refer to CCITT which now is ITU-T
I just made the change frmo CCITT to ITU-T. The result of a make update looks OK, so I think that resolves this ticket. [jaenicke - Thu Jun 13 13:55:36 2002]: [jaenicke - Mon Jun 10 17:42:40 2002]: I have made some further modifications: I did not like the direct use of 2 23 42 for SET (even though correct of course) but wanted to build the tree from the root. While doing this I noted, that the CCITT has long since been renamed to ITU-T. I therefore made some additional changes to use the new name and prepare aliases for CCITT. * It should be no problem to apply this to 0.9.8. * I am afraid to break things beyond NID_uniqueIdentifier in 0.9.7. (Due to the alias for CCITT nothing should happen, though). Ok, I have checked in the SET stuff for 0.9.7 and later. I have left out any CCITT-ITU-T renaming for now and will move this ticket with a new subject to the 0.9.8 queue. Best regards, Lutz -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #299] Re: Unique DNs
I solved this a little while ago. 'openssl ca' defaults to unique DNs, but can be made work ilke you want with the configuration option 'unique_subject' See the docs at http://www.openssl.org/docs/apps/ca.html#CONFIGURATION_FILE_OPTIONS as well as usage examples in. Note that when after the first use, you will see a file index.txt.attr alongside with index.txt, which will contain the setting for unique_subject. After that, it doesn't matter what you have in your configuration file. This is to avoid messups if the configuration file is edited and unique_subject is changed. And oh, the change is for 0.9.8 and on only. [EMAIL PROTECTED] - Wed Oct 2 14:41:16 2002]: Hi, I modified a patch which I received from Christophe Bailleux [EMAIL PROTECTED]. The original patch simply deactivate all parts of OpenSSL which checks for a unique DN. The attached patch adds an option -nouniqueDN to ca.c. The attached patch was made from 0.9.7 but it should be applied to the HEAD-branch because 0.9.7 is frozen. The patch requires the use of -nouniqueDN for revocation too. This is necessary because ca.c tries to build an index from the DNs. Any comments? Michael -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Because, I could stub the default implementation, and if the error handling has been disabled, then I just don't call the default implementation function. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 04, 2003 1:52 PM Subject: Re: [openssl.org #629] Custom error handling In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) groups is fine when a child function is adding a new error, however, what happends groups when it calls ERR_clear_error ? In my implementation I need the error stack groups to be preserved even if a child function calls ERR_clear_error. groups groups That's why if you happended to remove the if (!err_fns) test in groups ERR_set_implementation, I would be more than happy. I'm sorry, but in what way does that prevent the error stack to be cleared? Maybe a better thing would be to have a flag that inhibits clearing the error stack... I'll ponder over this issue. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
Because, I could stub the default implementation, and if the error handling has been disabled, then I just don't call the default implementation function. Frédéric Giudicelli http://www.newpki.org - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 04, 2003 1:52 PM Subject: Re: [openssl.org #629] Custom error handling In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: groups The problem is the following, yes your code (ERR_pop_to_mark/ERR_set_mark) groups is fine when a child function is adding a new error, however, what happends groups when it calls ERR_clear_error ? In my implementation I need the error stack groups to be preserved even if a child function calls ERR_clear_error. groups groups That's why if you happended to remove the if (!err_fns) test in groups ERR_set_implementation, I would be more than happy. I'm sorry, but in what way does that prevent the error stack to be cleared? Maybe a better thing would be to have a flag that inhibits clearing the error stack... I'll ponder over this issue. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
OK, what stops you from creating your own implementation table and fill that with whatever you want, and give that as an argument to ERR_set_implementation(). I know, it means you have to look in crypto/err/err.c for each version to see if there's been a change to ERR_FNS. Guess what? It sounds like you must fiddle with that file eaither way... -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 20:02:15 +0200 (METDST), Frédéric Giudicelli via RT [EMAIL PROTECTED] said: rt Because, I could stub the default implementation, and if the error rt handling has been disabled, then I just don't call the default rt implementation function. rt rt Frédéric Giudicelli rt http://www.newpki.org rt rt rt - Original Message - rt From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] rt To: [EMAIL PROTECTED]; [EMAIL PROTECTED] rt Cc: [EMAIL PROTECTED] rt Sent: Friday, July 04, 2003 1:52 PM rt Subject: Re: [openssl.org #629] Custom error handling rt rt rt In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 rt 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: rt rt groups The problem is the following, yes your code rt (ERR_pop_to_mark/ERR_set_mark) rt groups is fine when a child function is adding a new error, however, what rt happends rt groups when it calls ERR_clear_error ? In my implementation I need the rt error stack rt groups to be preserved even if a child function calls ERR_clear_error. rt groups rt groups That's why if you happended to remove the if (!err_fns) test in rt groups ERR_set_implementation, I would be more than happy. rt rt I'm sorry, but in what way does that prevent the error stack to be rt cleared? Maybe a better thing would be to have a flag that inhibits rt clearing the error stack... I'll ponder over this issue. rt rt -- rt Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] rt [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 rt \ SWEDEN \ or +46-708-26 53 44 rt Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] rt Member of the OpenSSL development team: http://www.openssl.org/ rt rt Unsolicited commercial email is subject to an archival fee of $400. rt See http://www.stacken.kth.se/~levitte/mail/ for more info. rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] rt rt rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #629] Custom error handling
OK, what stops you from creating your own implementation table and fill that with whatever you want, and give that as an argument to ERR_set_implementation(). I know, it means you have to look in crypto/err/err.c for each version to see if there's been a change to ERR_FNS. Guess what? It sounds like you must fiddle with that file eaither way... -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 20:02:15 +0200 (METDST), Frédéric Giudicelli via RT [EMAIL PROTECTED] said: rt Because, I could stub the default implementation, and if the error rt handling has been disabled, then I just don't call the default rt implementation function. rt rt Frédéric Giudicelli rt http://www.newpki.org rt rt rt - Original Message - rt From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] rt To: [EMAIL PROTECTED]; [EMAIL PROTECTED] rt Cc: [EMAIL PROTECTED] rt Sent: Friday, July 04, 2003 1:52 PM rt Subject: Re: [openssl.org #629] Custom error handling rt rt rt In message [EMAIL PROTECTED] on Fri, 4 Jul 2003 rt 00:12:24 +0200, Frédéric Giudicelli [EMAIL PROTECTED] said: rt rt groups The problem is the following, yes your code rt (ERR_pop_to_mark/ERR_set_mark) rt groups is fine when a child function is adding a new error, however, what rt happends rt groups when it calls ERR_clear_error ? In my implementation I need the rt error stack rt groups to be preserved even if a child function calls ERR_clear_error. rt groups rt groups That's why if you happended to remove the if (!err_fns) test in rt groups ERR_set_implementation, I would be more than happy. rt rt I'm sorry, but in what way does that prevent the error stack to be rt cleared? Maybe a better thing would be to have a flag that inhibits rt clearing the error stack... I'll ponder over this issue. rt rt -- rt Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] rt [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 rt \ SWEDEN \ or +46-708-26 53 44 rt Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] rt Member of the OpenSSL development team: http://www.openssl.org/ rt rt Unsolicited commercial email is subject to an archival fee of $400. rt See http://www.stacken.kth.se/~levitte/mail/ for more info. rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] rt rt rt __ rt OpenSSL Project http://www.openssl.org rt Development Mailing List [EMAIL PROTECTED] rt Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
