In message <584d7f4e.8090...@roumenpetrov.info> on Sun, 11 Dec 2016 18:31:10
+0200, Roumen Petrov said:
openssl> One remark for store load function api - in most cases (load from
openssl> file) it is password callback but is other cases it could be PIN or
openssl> something different.
openssl> P
Roumen Petrov skrev: (11 december 2016 17:31:10 CET)
>Hi Richard,
>
>Richard Levitte wrote:
>> In message<20161206.223057.237264374331072901.levi...@openssl.org>
>on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard
>Levitte said:
>>
>> levitte> [SNIP]
>>
>> The easiest was actually to rewrite PE
Hi Richard,
Richard Levitte wrote:
In message<20161206.223057.237264374331072901.levi...@openssl.org> on Tue, 06 Dec
2016 22:30:57 +0100 (CET), Richard Levitte said:
levitte> [SNIP]
The easiest was actually to rewrite PEM_read_bio_PrivateKey()
entirely, so it solely uses the internal store_
HI Richard,
Richard Levitte wrote:
In message<58472e4f.3010...@roumenpetrov.info> on Tue, 06 Dec 2016 23:31:59 +0200,
Roumen Petrov said:
openssl> Hi Richard,
openssl>
[SNIP]
openssl> > Check. My STORE branch is made to support that.
openssl> One URI could represent more then one item.
open
On Fri, 2016-12-09 at 00:25 +, David Woodhouse wrote:
> On Thu, 2016-12-08 at 16:22 -0800, James Bottomley wrote:
> >
> > I'm guessing you mean this:
> >
> > https://www.trustedcomputinggroup.org/wp-content/uploads/TSS_Versio
> > n_1.2_Level_1_FINAL.pdf
> >
> > ? It still doesn't tell you w
On Thu, 2016-12-08 at 16:22 -0800, James Bottomley wrote:
>
> I'm guessing you mean this:
>
> https://www.trustedcomputinggroup.org/wp-content/uploads/TSS_Version_1.2_Level_1_FINAL.pdf
>
> ? It still doesn't tell you who the expected parent of the key would
> be, which is the problem I'm curren
On Thu, 2016-12-08 at 15:56 -0800, James Bottomley wrote:
> On Thu, 2016-12-08 at 23:44 +, David Woodhouse wrote:
> > On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> > > Oh
> > >
> > > I think I aired some thoughts on using PEM headers a very long
> > > while
> > > ago, but tha
On Thu, 2016-12-08 at 23:44 +, David Woodhouse wrote:
> On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> > Oh
> >
> > I think I aired some thoughts on using PEM headers a very long
> > while
> > ago, but that never came into fruition, among others because I
> > ended
> > up doub
On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> Oh
>
> I think I aired some thoughts on using PEM headers a very long while
> ago, but that never came into fruition, among others because I ended
> up doubting that it would be the best way in the long run.
>
> These days, the use o
On 12/06/2016 10:42 PM, Richard Levitte wrote:
> The easiest was actually to rewrite PEM_read_bio_PrivateKey()
> entirely, so it solely uses the internal store_file functions I've
> provided.
> I wonder what kind of impact this would have on the community at
> large.
>
If you do that, please ensur
In message <20161206.223057.237264374331072901.levi...@openssl.org> on Tue, 06
Dec 2016 22:30:57 +0100 (CET), Richard Levitte said:
levitte> That being said, it should certainly be easy enough to change the
levitte> appropriate places to make sure headers are available as well, and I
levitte> ha
In message <58472e4f.3010...@roumenpetrov.info> on Tue, 06 Dec 2016 23:31:59
+0200, Roumen Petrov said:
openssl> Hi Richard,
openssl>
openssl> Richard Levitte wrote:
openssl> > [SNIP]
openssl> > James.Bottomley> 1. We agreed that usability is greatly enhanced if
openssl> > openssl simply loads
Hi Richard,
Richard Levitte wrote:
[SNIP]
James.Bottomley>1. We agreed that usability is greatly enhanced if openssl
simply loads
James.Bottomley> a key when presented with the file/uri etc. without the
user having
James.Bottomley> to specify what the format of a key is
Check.
In message <1481043672.4406.22.ca...@hansenpartnership.com> on Tue, 06 Dec 2016
09:01:12 -0800, James Bottomley said:
James.Bottomley> On Tue, 2016-12-06 at 17:47 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1481042048.4406.14.ca...@hansenpartnership.com>
on Tue,
James.Bottomley
On 12/06/2016 11:01 AM, James Bottomley wrote:
> The next problem is that this is slightly harder simply to insert into
> the PEM code. The BIO parsing is done in PEM_bytes_read_bio() not
> PEM_read_bio_PrivateKey(). The easy way to cope with this would be to
> move PEM parsing into the ENGINE_f
On Tue, 2016-12-06 at 17:47 +0100, Richard Levitte wrote:
> In message <1481042048.4406.14.ca...@hansenpartnership.com> on Tue,
> 06 Dec 2016 08:34:08 -0800, James Bottomley <
> james.bottom...@hansenpartnership.com> said:
>
> James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte
> w
In message <1481042048.4406.14.ca...@hansenpartnership.com> on Tue, 06 Dec 2016
08:34:08 -0800, James Bottomley said:
James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1480697558.2410.33.ca...@hansenpartnership.com>
on Fri,
James.Bottomley
On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote:
> In message <1480697558.2410.33.ca...@hansenpartnership.com> on Fri,
> 02 Dec 2016 08:52:38 -0800, James Bottomley <
> james.bottom...@hansenpartnership.com> said:
>
> James.Bottomley> On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte
> w
In message <1480697558.2410.33.ca...@hansenpartnership.com> on Fri, 02 Dec 2016
08:52:38 -0800, James Bottomley said:
James.Bottomley> On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote:
James.Bottomley> >
James.Bottomley> > James Bottomley
skrev: (1
James.Bottomley> > december 2016 07:
On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote:
>
> James Bottomley skrev: (1
> december 2016 07:36:26 CET)
> > On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
> > >
> > > James Bottomley skrev: (1
> > > december 2016 00:42:09 CET)
[...]
> > > > On Thu, 2016-12-01 at 00:22 +
James Bottomley skrev: (1 december 2016
07:36:26 CET)
>On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
>>
>> James Bottomley skrev: (1
>> december 2016 00:42:09 CET)
>> > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
>> > > This patch doesn't fit the rest...
>> >
>> >
On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote:
>
> James Bottomley skrev: (1
> december 2016 00:42:09 CET)
> > On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
> > > This patch doesn't fit the rest...
> >
> > I'm not quite sure I follow why.
>
> It casts bp to const char *.
James Bottomley skrev: (1 december 2016
00:42:09 CET)
>On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
>> This patch doesn't fit the rest...
>
>I'm not quite sure I follow why.
It casts bp to const char *. That was for your earlier implementation, wasn't
it? It doesn't fit the late
On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
> This patch doesn't fit the rest...
I'm not quite sure I follow why. To allow engines to load PEM encoded
engine keys in place of machine processed ones, the hook into the
loader has to be in somewhere. This seems to be the most generic
This patch doesn't fit the rest...
Generally speaking, I am unsure about your solution. It seems like hack to fit
a specific case where something more general could be of greater service to
others as well.
Cheers
Richard
On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley
wrote:
>
> I suspect IBM will need to sign a CCLA ... they'll definitely need to know who
> your lawyers are.
We have a CCLA from IBM; contact Christopher Barrett.
> I did check those links ... they don't have any governance information about
> the actual openssl foundation that I can find.
If you want p
On Wed, 2016-11-30 at 19:32 +, Salz, Rich wrote:
> > OK, so where is the foundation charter and who are your lawyers?
>
> Wow, this seems to have taken a turn to the unfriendly. I apologize
> if I added to that. Sometimes a smiley doesn't wipe out all bad
> impressions.
No, it's standard if
> OK, so where is the foundation charter and who are your lawyers?
Wow, this seems to have taken a turn to the unfriendly. I apologize if I added
to that. Sometimes a smiley doesn't wipe out all bad impressions.
The OpenSSL Software Foundation is incorporated in the the state of Delaware,
Uni
On Wed, 2016-11-30 at 17:59 +, Salz, Rich wrote:
>
> > Plus the DCO is industry best practice: even OpenStack is adopting
> > it after a
> > long struggle.
>
> Great. Good for them.
>
> This is what we're doing.
>
> :)
OK, so where is the foundation charter and who are your lawyers?
Jam
> Plus the DCO is industry best practice: even OpenStack is adopting it after a
> long struggle.
Great. Good for them.
This is what we're doing.
:)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Wed, 2016-11-30 at 16:04 +, Salz, Rich wrote:
> > Groan ... since you're changing licences, I don't suppose you'd
> > consider moving to a DCO model.
>
> Sorry, no. Legal advice and best practices.
Interesting: whose legal advice? I assumed you were talking to the
SFLC and I thought the
> Actually, being a kernel developer, email is far easier. I'll send a pull
> request
> when everyone's OK with the mechanism, plus it will need tests and other
> things.
Well... okay. I don't know how the community will react. But I *do* know that
the team prefers things as PR's.
> Groan
> Thanks for working to improve openssl.
You're welcome.
> It is probably easier for you to do a GitHub pull request and then
> have discussion here, pointing to that PR.
Actually, being a kernel developer, email is far easier. I'll send a
pull request when everyone's OK with the mechanism, plu
Thanks for working to improve openssl.
It is probably easier for you to do a GitHub pull request and then have
discussion here, pointing to that PR.
And also, before any of this code could be used, we'll need the appropriate CLA.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.or
Before trying to process the PEM file, hand it to each of the loaded
engines to see if they recognise the PEM guards. This uses the new
bio based load key callback, so the engine must be loaded and
implement this callback to be considered.
Signed-off-by: James Bottomley
---
crypto/pem/pem_pkey.
35 matches
Mail list logo
