apps.c has a couple of parsing routines called load_pubkey and
load_key. rsautl uses those routines.
However, there's no option in rsautil to use anything other than a
ASN.1/DER or PEM encoded traditional key (or subject public key info).
The code paths are present, we just can't seem to get to th
> > (Documentation is in the source files, not a .pod)
>
> Do you have code to produce usable manpages from the embedded
> documentation? We can't ask users to read the source.
I believe Todd meant for the test program.
> * The copyright notice does not refer to any license that would all
Many of the changes Akamai has did not include proper documentation. I have
noted these and will send updated patches when done. I will also update the
copyrights.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."
> On May 31, 2015, at 9:27 AM, S
Many of the changes Akamai has did not include proper documentation. I have
noted these and will send updated patches when done. I will also update the
copyrights.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."
> On May 31, 2015, at 9:27 AM, S
Nice idea, I'm however thinking that much of the trying different formats could
be moved to load_key / load_pubkey, all that would be needed is a keyformat
denoting "try anything". -1, perhaps?
On Sun May 31 09:46:28 2015, noloa...@gmail.com wrote:
> apps.c has a couple of parsing routines called
You solution does the following:
if (lh_SSL_SESSION_retrieve(p->cache, s) == s) {
(void)lh_SSL_SESSION_delete(p->cache, s);
...
Would you agree that the following does the same?
if (lh_SSL_SESSION_delete(p->cache, s) == s) {
...
On Sat May 30 09:48:06 2015, tsh...@akamai.com wrote:
> Hello Ope
It's unclear to me what needs to change. Would you mind helping us figure it
out?
On Tue May 26 20:06:21 2015, rhida...@indra.es wrote:
> Make Output (tail ):
>
> >>> Makefile: line 206: Defined macro CLEARENV=TOP= && unset TOP
> $${LIB+LIB} $${LIBS+LIBS} $${INCLUDE+INCLUDE}
> $${INCLUDES+INCLUDES
No,
The second code sample removes a matching instance, but not necessarily the
same instance. If they are not the same instance, then it would need to be
re-inserted in and else clause.
This is a fine distinction.
This would leave to having the list and hash not contain the same contents:
No,
The second code sample removes a matching instance, but not necessarily the
same instance. If they are not the same instance, then it would need to be
re-inserted in and else clause.
This is a fine distinction.
This would leave to having the list and hash not contain the same contents:
I'm not sure how that can happen, as each SSL_SESSION in that lhash will have
unique content. This is assured by the way lh_insert functions and by
ssl_session_cmp (which gets called by getrn in lhash.c, via the function
pointer cf).
So while your suggestion will most probably work as a band aid,
We (Akamai) had a bad session compare function at one point; the compare was
fixed, but also added this change to protect the LHASH.
So, yes, this can only really happen if one has a bad comparison function.
--
-Todd Short
// tsh...@akamai.com
// Sent from my iPhone
// "One if by land, two if b
We (Akamai) had a bad session compare function at one point; the compare was
fixed, but also added this change to protect the LHASH.
So, yes, this can only really happen if one has a bad comparison function.
--
-Todd Short
// tsh...@akamai.com
// Sent from my iPhone
// "One if by land, two if b
Hmm, but does it? If you look for the comment '/* We *are* in trouble ... */'
in ssl_sess.c, you'll see that there is a similar kind of protection in place
already at the time of insert. So quite frankly and with all respect, I'm not
sure if this particular fix does anything of value any longer.
O
On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT
wrote:
> Nice idea, I'm however thinking that much of the trying different formats
> could
> be moved to load_key / load_pubkey, all that would be needed is a keyformat
> denoting "try anything". -1, perhaps?
>
I like the idea, and I was
On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT
wrote:
> Nice idea, I'm however thinking that much of the trying different formats
> could
> be moved to load_key / load_pubkey, all that would be needed is a keyformat
> denoting "try anything". -1, perhaps?
>
I like the idea, and I was
I submitted this earlier, but I forgot to tweak the docs. The docs
were missing the -keyform option, and they needed the behavior change
documented.
I also fixed a typo in the patch. The following was missing an 'else if':
if(keyformat == FORMAT_PEM) {
next_format = FORMAT_PEMRSA;
16 matches
Mail list logo
