I fixed this on my local ubuntu 14.04 box by doing ³apt-get install
libjpeg-dev²
Can we just make that a low level package dependency on the images in gate
so that
We can move forward?
On 10/1/15, 5:48 PM, "Kevin L. Mitchell"
wrote:
>It looks like Pillow (pulled in by blockdiag, pulled in by
>sp
If its because of an Error like "ValueError: --enable-jpeg requested
but jpeg not found, aborting² triggered by a dependency pull of
Python pillow which then I got around it by doing an ³apt-get install
libjpeg-dev² on my ubuntu build.
I agree its seemed odd when it happened on tox but not on p
te's X509 by using getCertificateX509 and returns
> SCN and SAN names dict.
>
> I will appreciate your opinion on this API.
>
> Thanks,
> Evg
>
>
> -Original Message-
> From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
> Sent: Thursday, July
Sorry I meant to say I'm pretty agreeable just park a stub module so I can
populate it.
On Jul 24, 2014, at 11:06 AM, Carlos Garza
wrote:
> I'Just park a module with a stub call that I can populate with
> pyasn1.
> On Jul 24, 2014, at 10:38 AM, Evgeny Fedoruk
I'Just park a madule with a stub call that I can populate with
pyasn1.
On Jul 24, 2014, at 10:38 AM, Evgeny Fedoruk
wrote:
> Hi,
>
> Following our talk on TLS work items split,
> We need to decide how will we validate/extract certificates Barbican TLS
> containers.
> As we agreed on IRC, the
ybody else who is interested will review this change.
>>> There is one specific spot for the common Barbican interactions
>>> module API integration.
>>> After the IRC meeting tomorrow, we can discuss the work items and
>>> decide who is interested/available to do t
make sense?
>
> Thanks,
> Evg
>
> -----Original Message-
> From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
> Sent: Wednesday, July 23, 2014 6:15 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS c
oday. It will include lbaas extension v2
> modification, lbaas db v2 modifications, alembic migration for schema changes
> and new tests in unit testing for lbaas db v2.
>
> Thanks,
> Evg
>
> -Original Message-
> From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
>
Since it looks like the TLS blueprint was approved I''m sure
were all eager to start coded so how should we divide up work on the
source code. I have Pull requests in pyopenssl
"https://github.com/pyca/pyopenssl/pull/143";. and a few one liners
in pica/cryptography to expose the needed low
On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk wrote:
> Hi folks,
>
> In a current version of TLS capabilities RST certificate SubjectCommonName
> and SubjectAltName information is cached in a database.
> This may be not necessary and here is why:
>
> 1. TLS containers are immutable, mea
x27;t see harm in extracting these other subjectAltName types from the
> x509 cert. It certainly "feels" more correct to treat these for what they
> are: the tuples you've described.
>
> Thanks,
> Stephen
>
>
>
> On Thu, Jul 17, 2014 at 2:29 PM, Carlos Ga
al of the spec in the next day
> or two.
>
> Thanks,
> Stephen
>
>
>
>
> On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff
> wrote:
> Just saw this thread after responding to the other:
>
> I'm in favor of Evgeny's proposal. It sounds li
the perspective of the SNI standard, there's no difference in how these
> fields should be treated, and if we were to treat SANs differently then we're
> both breaking the standard and setting a bad precedent.
>
> Stephen
>
>
> On Tue, Jul 15, 2014 at 9:35 AM,
On Jul 16, 2014, at 3:49 PM, Carlos Garza wrote:
>
> On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam
>
> wrote:
>
>We will have the code that will parse the X509 in the API scope of the
> code. The validation I'm refering to is making sure the key matches th
used by multiple drivers is
> going to be necessary.
>
> If we're extracting the Subject Common Name in any place in the code then we
> also need to be extracting the Subject Alternative Names at the same place.
> From the perspective of the SNI standard, there's no d
o be necessary.
>
> If we're extracting the Subject Common Name in any place in the code then we
> also need to be extracting the Subject Alternative Names at the same place.
> From the perspective of the SNI standard, there's no difference in how these
> fields should
On Jul 15, 2014, at 10:55 AM, Samuel Bercovici
wrote:
> Hi,
>
>
> Obtaining the domain name from the x509 is probably more of a
> driver/backend/device capability, it would make sense to have a library that
> could be used by anyone wishing to do so in their driver code.
You can do wh
On Jul 15, 2014, at 9:24 AM, Evgeny Fedoruk wrote:
> The question is about SCN and SAN extraction from X509.
> 1. Extraction of SCN/ SAN should be done while provisioning and not
> during TLS handshake
Yes that makes the most sense. If some strange backend really wants to
repeatedly e
On Jun 28, 2014, at 12:01 AM, Carlos Garza
wrote:
>>
>> example python script using your example pem file. If using NSS isn't an
>> option I'd rather see us provide the necessary binding in pyopenssl than
>> handcraft one-off routines.
Are you saying y
On Jun 27, 2014, at 9:26 AM, John Dennis wrote:
> On 06/27/2014 12:21 AM, Carlos Garza wrote:
>> I don't know where we can check in experimental code so I have a
>> demonstration
>> of how to extract CNs subjAltNames or what ever we want from x509
>> cer
to.
>
> -Dustin
>
>
> On Fri, Jun 27, 2014 at 7:26 AM, John Dennis wrote:
> On 06/27/2014 12:21 AM, Carlos Garza wrote:
> > I don't know where we can check in experimental code so I have a
> > demonstration
> > of how to extract CNs subjAltNames or
I don't know where we can check in experimental code so I have a
demonstration
of how to extract CNs subjAltNames or what ever we want from x509 certificates.
Later on
I plan to use the OpenSSL libraries to verify certs coming from barbican are
valid and
actually do sign the private_key
On Jun 16, 2014, at 4:06 PM, Clint Byrum wrote:
> Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700:
>>> nobody is calling Barbican "a database". It is a place to store
>>
>> Š did you at least feel a heavy sense of irony as you typed those two
>> statements? ³It¹s not a databa
On Jun 16, 2014, at 3:22 PM, Doug Wiegley wrote:
>> nobody is calling Barbican "a database". It is a place to store
>
> Š did you at least feel a heavy sense of irony as you typed those two
> statements? ³It¹s not a database, it just stores things!² :-)
>
> The real irony here is that in thi
Sorry for responding so late but I don't think we should be doing ref
counting at all.
In a closed system its hard enough to guarantee they are correct but in an open
distributed system I really doubt every service will bother decrementing and
incrementing the counters properly.
On Jun 16,
On Jun 11, 2014, at 9:31 AM, Evgeny Fedoruk wrote:
> Regarding the case when back-end system tries to retrieve secret from deleted
> Barbican TLS container,
> Is this a real use case? I mean, is there a back-end system which will get
> container ID from somewhere, try to retrieve secrets from
On Jun 10, 2014, at 3:11 PM, Stephen Balukoff wrote:
> Hi Evgeny,
>
> Comments inline.
>
> On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk wrote:
> Hi All,
>
>
>
> Carlos, Vivek, German, thanks for reviewing the RST doc.
>
> There are some issues I want to pinpoint final decision on them
On Jun 10, 2014, at 2:53 PM, Doug Wiegley
wrote:
>> In any case, it strikes me as misleading to have an explicit delete command
>> sent to Barbican not have the effect of making the key unusable in all other
>> contexts. It would be less surprising behavior, IMO, to have a deleted
>> barbican
See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron
LBaaS Integration Ideas.
He's advocating keeping a shadow copy of the private key that is owned by the
LBaaS service so that incase a key is tampered with during an
LB update migration etc we can still check with the shad
Ok but we still need input from Stephen Balukoff and Jorge to see how this
will integrate with the API being proposed. I'm not sure if they were intending
to use the attributes your discussing as well as which object was going to
contain them.
On Jun 10, 2014, at 6:13 AM, Evgeny Fedoruk
wrote:
The use case was that a cert inside the container could be updated while the
private key stays the same. IE a new cert would be a resigning of the same old
key. By immutable we mean to say that the same UUID would be used on the lbaas
side. This is a heavy handed way of expecting the user to
The barbican team was considering making the container mutable but I don't
think it matters now
since every one has chimed in and wants the container to be immutable. The
current discussion now is that
the TLS container will be immutable but the meta data will not be.
I'm not sure what is mea
I understand this concern and was advocating that a configuration option be
available to disable or enable auto updating of SSL certificates. But since
every one is in favor of storing meta data on the barbican container directly I
guess this is a moot point now.
On Jun 6, 2014, at 5:52 PM,
On May 27, 2014, at 9:13 PM, Stephen Balukoff
wrote:
> Hi y'all!
>
> I would advocate that if the user asks the front-end API for the private key
> information (ie. "GET" request), what they get back is the key's modulus and
> nothing else. This should work to verify whether a given key matc
Right so are you advocating that the front end API never return a
private key back to the user once regardless if the key was generated
on the back end or sent in to the API from the user? We kind of are
already are implying that they can refer to the key via a private
key id.
On May 23, 20
:samu...@radware.com>> wrote:
Hi Carlos,
What is your IRC nick?
In what time zone you are located?
Regards,
-Sam.
From: Carlos Garza [mailto:carlos.ga...@rackspace.com<http://rackspace.com>]
Sent: Wednesday, May 21, 2014 2:52 AM
To: OpenStack Development Mailing List (not fo
I'm reading through the https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
docs as well as the https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7
document that your referencing below and I think who ever wrote the documents
may have misunder stood the Association between X509 certificates a
On May 10, 2014, at 1:52 AM, Eugene Nikanorov
wrote:
> Hi Carlos,
> I think you had a chance to hear this argument yourself (from several
> different core members: Mark McClain, Salvatore Orlando, Kyle Mestery) on
> those meetings we had in past 2 months.
> I was advocating 'loadbalancer' (in
On May 9, 2014, at 3:36 PM, Eugene Nikanorov
mailto:enikano...@mirantis.com>>
wrote:
Also we've heard objection to this approach several times from other core team
members (this discussion has been going for more than half a year now), so I
would suggest to move forward with single L2 port ap
On May 9, 2014, at 3:37 PM, Samuel Bercovici
mailto:samu...@radware.com>>
wrote:
It boils down to two aspects:
1. How common is it for tenant to care about affinity or have more than a
single VIP used in a way that adding an additional (mandatory) construct makes
sense for them to handl
ing such as neutron/lbaas and interpret it to be "Virtual Ips as a
service. We've done that with our API in CLB1.0.
Carlos.
Eugene.
On Fri, May 9, 2014 at 8:33 AM, Carlos Garza
mailto:carlos.ga...@rackspace.com>> wrote:
On May 8, 2014, at 2:45 PM, Eugene Nikanorov
mailto:enika
On May 8, 2014, at 2:45 PM, Eugene Nikanorov
mailto:enikano...@mirantis.com>> wrote:
Hi Carlos,
Are you saying that we should only have a loadbalancer resource only in the
case where we want it to span multiple L2 networks as if it were a router? I
don't see how you arrived at that conclu
On May 8, 2014, at 8:01 AM, Eugene Nikanorov
mailto:enikano...@mirantis.com>>
wrote:
Hi Adam,
My comments inline:
1. We shouldn't be looking at the current model and deciding which object is
the root object, or what object to rename as a "loadbalancer"... That's
totally backwards! *We don'
ners
if you really wanted to
(https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container)
-Rob
From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: 08 May 2014 04:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neu
On May 7, 2014, at 10:53 AM, Samuel Bercovici
mailto:samu...@radware.com>> wrote:
Hi John,
If the user already has an SSL certificate that was acquired outside of the
barbican Ordering system, how can he store it securely in Barbican as a SSL
Certificate?
The Container stored this information
I thought the requirement was from the need to ensure the backend was
secure. IE people would throw a fit if they find out your storing keys in
sqllite or MySQL. Wasn't the purpose to find "A Secure repository"?
On May 7, 2014, at 10:38 AM, Zang MingJie wrote:
> +1 to implement a modular f
On May 1, 2014, at 7:48 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>>
wrote:
Hi Trevor,
I was the one who wrote that use case based on discussion that came out of the
question I wrote the list last week about SSL re-encryption: Someone had
stated that sometimes pool members are local,
our stingray nodes don't allow you to specify. Its just an enable or disable
option.
On May 1, 2014, at 7:35 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>>
wrote:
Question for those of you using the SSL session ID for persistency: About how
long do you typically set these sessions to p
Balukoff I'm liking your API spec so far but can you elaborate on what
this loadbalancer object you refer to is. on page You declare its immutable and
refer to it like an actual primitive object yet I don't
see a schema for it. I see loadbalancer_id in the vip request that reference.
The to
This blueprint was marked abandoned.
On Apr 29, 2014, at 3:55 PM, Vijay B
mailto:os.v...@gmail.com>>
wrote:
Hi Sam, Evgeny,
I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am not
sure if there is a request with code newer than this link - please do let me
know if
On Apr 27, 2014, at 8:35 AM, Eugene Nikanorov
mailto:enikano...@mirantis.com>> wrote:
On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov
mailto:enikano...@mirantis.com>> wrote:
Speaking of SSL - we have a few few project-wise issues such as lack of secure
storage, lack of secure messaging, req
I mis quoted it should be in RFC 5246 not 5264.
On Apr 25, 2014, at 2:50 AM, Carlos Garza
mailto:carlos.ga...@rackspace.com>> wrote:
Trevor is referring to our plans on using the SSL session ID of the
ClientHello to provide session persistence.
See RFC 5264 section 7.4.1.2 which se
Trevor is referring to our plans on using the SSL session ID of the
ClientHello to provide session persistence.
See RFC 5264 section 7.4.1.2 which sends an SSL session ID in the clear
(Unencrypted) so that a load balancer with out the decrypting key can use it to
make decisions on which
back
members.
What are people seeing "in the wild"? Are your users using
inconsistently-signed or per-node self-signed certs in a single pool?
Thanks,
Stephen
On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza
mailto:carlos.ga...@rackspace.com>> wrote:
On Apr 18, 2014, at 12:36 PM, Ste
end certs are all individually self-signed (ie. no single CA used for
all nodes), then certs must be associated with members.
I'm not invested in an argument this far in.
What are people seeing "in the wild"? Are your users using
inconsistently-signed or per-node self
On Apr 18, 2014, at 12:36 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>> wrote:
Dang. I was hoping this wasn't the case. (I personally think it's a little
silly not to trust your service provider to secure a network when they have
root access to all the machines powering your cloud... b
On Apr 18, 2014, at 12:59 PM, Vijay Venkatachalam
mailto:vijay.venkatacha...@citrix.com>> wrote:
There is no reasoning mentioned in AWS, but they do allow re-encryption.
Is their also no reason to mention:
BigIp's F5 LoadBalancers
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/p
On Apr 18, 2014, at 10:21 AM, Stephen Balukoff wrote:
> Howdy, folks!
>
> Could someone explain to me the SSL usage scenario where it makes sense to
> re-encrypt traffic traffic destined for members of a back-end pool? SSL
> termination on the load balancer makes sense to me, but I'm having
On Apr 17, 2014, at 8:39 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>>
wrote:
Hello German and Brandon!
Responses in-line:
On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan
mailto:brandon.lo...@rackspace.com>> wrote:
Stephen,
I have responded to your questions below.
On 04/17/2014 01:0
On Apr 17, 2014, at 5:49 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>>
wrote:
Heyas, y'all!
So, given both the prioritization and usage info on HA functionality for
Neutron LBaaS here:
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing
On Apr 17, 2014, at 2:11 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>>
wrote:
Oh! One other question:
5. Should "single-call" stuff work for the lifecycle of a load balancing
service? That is to say, should "delete" functionality also clean up all
primitives associated with the service
On Apr 17, 2014, at 8:45 AM, Eugene Nikanorov
mailto:enikano...@mirantis.com>>
wrote:
Brandon,
Towards the bottom of that document it does mention content switching and how
it would work with this. I know its a huge text document and hard to navigate
but it is there.
Yeah, i should have b
but could
probably have a draft to show y'all at next week's meeting if y'all think it
would be helpful to produce such a thing. Anyway, we can discuss this at
tomorrow's meeting…
Yes we are very interested in your concrete ideas. So far all we saw on ssl
is an entr
On Apr 16, 2014, at 4:31 PM, Eugene Nikanorov
mailto:enikano...@mirantis.com>> wrote:
Hi folks,
I've briefly looked over the doc.
I think whole idea to base the API on Atlas misses the content switching use
case, which is very important:
We need multiple pools within loadbalancer, and API doe
On Apr 14, 2014, at 8:20 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>> wrote:
Hello y'all!
Over the last few months, I feel like we've seen a renewed vigor for
participation in making the LBaaS project successful. After the (still
unresolved) object model discussion started in January,
65 matches
Mail list logo
