On 09/27/2013 09:38 PM, karanpopali wrote:
> In the FIPS User Guide (http://www.openssl.org/docs/fips/UserGuide-2.0.pdf),
> there is example to set the default DRBG type. It uses DRBG type as
> NID_hmac_WithSHA256, but it should be NID_hmacWithSHA256.
>
> Example from UserGuide:
> ./config -DOPENS
On Thursday 06 May 2004 08:45, Jim Schneider wrote:
> Here's a patch for d2i_SSL_SESSION.pod, pointing out a pitfall when using
> i2d_SSL_SESSION
Actually, that wasn't as clear as it should be - pp isn't getting clobbered,
what it points to (*pp) is getting clobbered.
On Sun, Nov 18, 2001 at 05:29:31PM -0500, [EMAIL PROTECTED] wrote:
> In http://www.openssl.org/docs/ssl/SSL_get_session.html#,
> "If the data is to be kept, SSL_get1_session() will increment the reference count
>and the
> session will stay in memory until explicitly freed with SSL_SESSION_free(3
These are no more c++ than my dog is president (although he would be
better than the US's other options). These are rote C. The names
should be changed to *.c within the source tree to aleviate linker
errors on several platforms.
--
Andrew
Alan wrote:
>
> On 28-Nov-2000 les wrote:
> > I'm not
On 28-Nov-2000 les wrote:
> I'm not sure if it's in every distro but in the latest stable release in
> openssl-0.9.6/demos/ssl/ there are two c+ files, cli.cpp and
> serv.cpp. they should give you a good starting point...
Ah, perfect. My appolagies, I'm on a debian system and completely for
On 28 Nov, Alan wrote:
> Are there any good sources of documentation on openssl? The man page gives
> some information, and I've found some examples in the list archives, but not
> quite what I'm looking for.
Wy do you need man pages when you can read source code? ;-)
> Anyway, what
> I'll be d
I'm not sure if it's in every distro but in the latest stable release in
openssl-0.9.6/demos/ssl/ there are two c+ files, cli.cpp and
serv.cpp. they should give you a good starting point...
At 01:55 PM 11/28/00 -0800, you wrote:
>Hi there, new to the list, just wanted to *wave* :)
>
>Are there
Lutz is right, there's lots of bad advice lurking on the email lists;
openssl-dev is better than openssl-users.
On the other hand, I think it will be easier to figure out who's right
and who's not. Whenever you get conflicting feedback, or from someone
you don't know, mark it off as "to be confi
Your English is at once clear and eloquent.
Allow me to parse what is available now, from old and
current sources. I will send it to the dev group and
to you. If acceptable; use it, display it, link to
it.
Let's tentatively commit to a draft user's guide by
Weihnachten perhaps? Anything is be
On Tue, Oct 24, 2000 at 09:26:36AM -0700, john traenky wrote:
> Allow me to parse what is available now, from old and
> current sources. I will send it to the dev group and
> to you. If acceptable; use it, display it, link to
> it.
The OpenSSL team members will take care of creating links, make
(Just came back from hiking in the Harz mountains late yesterday evening.)
On Fri, Oct 20, 2000 at 12:37:08PM -0700, john traenky wrote:
> I read you too work on documentation. I would like to
> join the work. How should I start? Should I gather
> notes about SSLeay and OpenSSL and create a us
From: Lutz Jaenicke <[EMAIL PROTECTED]>
Lutz.Jaenicke> I have further changed some to the "NOTES" style
Lutz.Jaenicke> recommended by Richard Levitte and added
Lutz.Jaenicke> SSL_CTX_set_ssl_version.
Or rather, put up for discussion. The rest was my opinion. Note also
that I reverted the chang
In article <[EMAIL PROTECTED]> you wrote:
> in the Makefile.ssl file, one can read:
> # If you change the INSTALLTOP, make sure to also change the values
> # in crypto/location.h
> ... but I can't find the file crypto/location.h
> The INSTALL file seems more correct and tell me to edit the crypt
On 22-Jan-99 Ben Laurie wrote:
> Sameer Parekh wrote:
>>
>> We may be misunderstanding each other. Let me outline my
>> position in pieces so we can see where we agree and where we
>> disagree, more specifically.
>>
>> a) I would like the OpenSSL project to protect the codebase from bein
> My discussions have had other conclusions, saying they'd be "foolish" to go
> after a big company. I think they were just trying to inti-
> midate you.
Perhaps. Not all multi-nationals are big however - Open Software Associates
in such an example. We still want to be able to use OpenSSL witho
> A US-related firm
>will not use illegally exported cryptography code for fear of stock
>market and government retribution.
Okay, that makes sense to me.
__
OpenSSL Project http://www.open
OK, you have a good point. Let me try again. A US-related firm
will not use illegally exported cryptography code for fear of stock
market and government retribution. I have direct experience with large
US-related firms for whom this has been an issue.
> > No. Its my contention that if
> No. Its my contention that if a US person exports crypto code >illegally,
>the US government will go after a US-related firm (i.e. a >multinational)
>who uses that code internationally. This is based on statements from
>government officials and discussions with export control attorneys.
M
Sameer Parekh wrote:
> > Anyone got any suggestions as to how we resolve this?
>
> My suggestion is that we find a US export lawyer (I know a few
> =) willing to provide the group with some advice pro bono, and the
> group can create guidelines based on that advice.
I'll go with that. Gi
> I suspect that there are people around who are going to disagree on what
> can and can't be exported, though, and I really am not at all sure how
> we can judge who is correct.
You can't. That's perhaps the biggest problem with the US export
regulations: all the "interesting" cases are decided
[good faith]
>
> OK. Is this explicitly stated somewhere, or is it an interpretation of
> regs? Has it been tested in court?
As far as I know it has not been tested in court. The regs on
export restricted web sites *do* explicitly mention good faith
effort. I think that the use of good f
ben> I suspect that there are people around who are going to disagree on what
ben> can and can't be exported, though, and I really am not at all sure how
ben> we can judge who is correct. For starters, we already see one camp that
ben> says "any source in OpenSSL is unexportable", and another that
Sameer Parekh wrote:
> > > b) I would like the OpenSSL project to require that all contributors
> > > warrant that the code they are contributing does not violate export
> > > controls.
> >
> > So long as _I_ don't have to collect these warranties, I can't see why
> > this should be a problem. I d
> I don't think that's quite correct. What it says is that strong
> encryption code can't be exported from the US, except to Canada.
> Thenationality of the person has nothing to do with it. Otherwise, it
> would just be for any company in the US to ask some foreign consultant
> to come to the s
> My problem with this is that it requires the OpenSSL project to be aware
> of export restrictions in other jurisdictions. If we really have to be
> aware, then so be it, but I'd be _much_ happier if we could only worry
> about our own. Can we not protect the codebase simply by asking that
> peop
>
> Examples would be certificate extension code, message digest algorithms
> or stuff related to authentication only (e.g. DSS).
>
> Or do you think even contributions of this sort could cause problems?
I beleive that this would be a problem because that would be a
US person providing
Sameer Parekh wrote:
>
> d) The OpenSSL project should not allow US persons to contribute to
> the OpenSSL source code.
>
This would be the easiest way to handle things but it might be regarded
as over cautious.
There are some non crypto areas of OpenSSL where US persons might be
able to contr
salzr> The export regulations say that US persons can't export. They
salzr> are silent on what happens after the code has gone offshore.
I don't think that's quite correct. What it says is that strong
encryption code can't be exported from the US, except to Canada.
Thenationality of the person h
Sameer Parekh wrote:
>
> We may be misunderstanding each other. Let me outline my
> position in pieces so we can see where we agree and where we
> disagree, more specifically.
>
> a) I would like the OpenSSL project to protect the codebase from being
> polluted with export-restricted cod
We may be misunderstanding each other. Let me outline my
position in pieces so we can see where we agree and where we
disagree, more specifically.
a) I would like the OpenSSL project to protect the codebase from being
polluted with export-restricted code, US or otherwise.
b) I would lik
At 11:08 AM 1/22/99 , [EMAIL PROTECTED] wrote:
>> US law may not apply to you, but it applies to many of the
>>people who are using OpenSSL outside the United States.
>
>Hmm, is it your contention that if a US person exports crypto code,
>then the US govt will come after non-US citizens who u
Sameer Parekh wrote:
>
> >
> > b) US law doesn't apply to me (at least while I'm not in US territory)
> > or OpenSSL, AFAIK, regardless of the code's origin.
> >
>
> US law may not apply to you, but it applies to many of the
> people who are using OpenSSL outside the United States. If it
> US law may not apply to you, but it applies to many of the
>people who are using OpenSSL outside the United States.
Hmm, is it your contention that if a US person exports crypto code,
then the US govt will come after non-US citizens who uses that code?
The export regulations say that US
>
> b) US law doesn't apply to me (at least while I'm not in US territory)
> or OpenSSL, AFAIK, regardless of the code's origin.
>
US law may not apply to you, but it applies to many of the
people who are using OpenSSL outside the United States. If its your
intention that multinationals
>
> This is true, but who outside the US gives a damn?
It's not just an issue for those outside the US. Its an issue
for multinational companies that wish to ship strong cryptography
products worldwide. If there's a company that does business in the US,
then they won't be able to u
From: Jon Parry-McCulloch <[EMAIL PROTECTED]>
> >Once the library contains crypto code of American origin,
> it is
> >covered by the American reexport regulations. That means
> that everyone
> >who distributes it internationally will violate US law.
>
>
In article <[EMAIL PROTECTED]> you wrote:
> Ralf S. Engelschall wrote:
>>
>> In article <[EMAIL PROTECTED]> you wrote:
>> > Ralf S. Engelschall wrote:
>>
>> [...]
>> >> IMHO it's ok to not give them access to the non-documentation stuff, because
>> >> this way we don't have to make sure people
Anonymous wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> wrote:
>
> > I'm totally against this. We have no responsibility to enforce the USG's
> > stupid export laws, and I see no reason we should take that
> > responsibility on.
>
> Once the library contains crypto code of American origin, it is
>
>Once the library contains crypto code of American origin,
it is
>covered by the American reexport regulations. That means
that everyone
>who distributes it internationally will violate US law.
This is true, but who outside the US gives a
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Ralf S. Engelschall wrote:
>
> [...]
> >> IMHO it's ok to not give them access to the non-documentation stuff, because
> >> this way we don't have to make sure people don't violate their export laws.
>
> > I'm totally
Ben Laurie <[EMAIL PROTECTED]> wrote:
> I'm totally against this. We have no responsibility to enforce the USG's
> stupid export laws, and I see no reason we should take that
> responsibility on.
Once the library contains crypto code of American origin, it is
covered by the American reexport reg
In article <[EMAIL PROTECTED]> you wrote:
> Ralf S. Engelschall wrote:
[...]
>> IMHO it's ok to not give them access to the non-documentation stuff, because
>> this way we don't have to make sure people don't violate their export laws.
> I'm totally against this. We have no responsibility to e
> I don't understand why US people can't be given access to the source
> tree.
Well they *can* be given access to the source tree, but the
idea, imo, is to make it easier to comply. That way a US person can't
have a modified version of the tree and then accidentally hit commit
and export
Ralf S. Engelschall wrote:
>
> In article <[EMAIL PROTECTED]> you
>wrote:
>
> > I don't understand why US people can't be given access to the source
> > tree.
>
> Sorry for my ignorance, but who said that we cannot give US people access to
> the source tree in general? Sure, we should perhaps
In article <[EMAIL PROTECTED]> you
wrote:
> I don't understand why US people can't be given access to the source
> tree.
Sorry for my ignorance, but who said that we cannot give US people access to
the source tree in general? Sure, we should perhaps make sure they cannot
commit to the non-docu
[EMAIL PROTECTED] wrote:
>
> I don't understand why US people can't be given access to the source
> tree.
I didn't understand that, either, but it didn't seem worth quibbling,
because there are other reasons, anyway...
> Is it because of a desire to "prove" that nobody from the US exported
> so
sameer wrote:
>
> So, I'm lame, and I haven't been paying too much attention to
> this list. I realized today, however, that it would be legit for me to
> work on documentation for OpenSSL. So what's the status on
> documentation? I'm thinking it would be appropriate to setup another
> CV
I don't understand why US people can't be given access to the source
tree.
Is it because of a desire to "prove" that nobody from the US exported
source code? Surely that's (a) too big a hammer (we can, e.g., con-
tribute to the ASN1 engine); (b) probably not sufficient proof; and
(c) starting do
Good point. There are certainly several folk in the US who
would/could help with that.
At 01:09 AM 1/19/99 -0800, you wrote:
> So, I'm lame, and I haven't been paying too much attention to
>this list. I realized today, however, that it would be legit for me to
>work on documentation for Op
49 matches
Mail list logo
