From Anil.Saldhana at redhat.com Tue Apr 1 09:11:24 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Tue, 01 Apr 2014 08:11:24 -0500 Subject: [security-dev] Security Interceptors in Java EE8 In-Reply-To: <533A1684.4070704@redhat.com> References: <533A1684.4070704@redhat.com> Message-ID: <533ABAFC.3040108@redhat.com> The survey item says: "Support for CDI based security interceptor for authorization decisions". Deltaspike influence. :) Pedro and I were discussing yesterday that it may be good to put up a PicketLink blog post on the website talking about how PL is simplifying security and showcase our quickstarts for the security interceptor. On 03/31/2014 08:29 PM, Shane Bryzak wrote: > Looks like security interceptors was a popular feature request for Java > EE8. Something we should probably get involved with I think? > > https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee From Anil.Saldhana at redhat.com Tue Apr 1 09:12:26 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Tue, 01 Apr 2014 08:12:26 -0500 Subject: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean In-Reply-To: <367285324.5598398.1396321062597.JavaMail.zimbra@redhat.com> References: <367285324.5598398.1396321062597.JavaMail.zimbra@redhat.com> Message-ID: <533ABB3A.7030603@redhat.com> Pedro, - how does the programmer figure out he is using the Identity bean in a stateless scope and other usage: session scope? - will it add complexity to the internal implementation? Regards, Anil On 03/31/2014 09:57 PM, Pedro Igor Silva wrote: > Hi All, > > Shane and I had a discussion today about PLINK-400 [1]. Which is basically about adding a stateless behavior to the Identity bean. > > Today the Identity bean is session scoped, which implies that an authenticated user has a corresponding session on the server. That is fine when you're using JSF as view technology and the JESSIONID cookie is used to track user session. Or even using HTML5 and JS from a browser. The point here is that you don't need to send anything special in order to know that a specific request came from an previously authenticated user. The cookie is always sent to and from the server. > > Recently, after some discussions about making PL even more suitable for mobile, we decided to add a stateless behavior to the Identity bean. Basically, instead of creating a session on the server for each authenticated user, we don't store anything. Every data consumed and produced during the authentication process is destroyed once the request is finished. This is a very important requirement when you don't want to consume server resources with users sessions, specially if you're writing a RESTful API. Another example is Anil's work to integrate Apache Camel with PL. > > Usually, those use cases are based on a token which is issued after a successful authentication. Subsequent calls to protected services will then require the token to be validated in order to know if the request is from an authenticated user or not. Or even check if the token is still valid, etc. > > We're pretty sure about adding this stateless nature to the Identity bean. But we would like to know from you if we should also support both "natures" from the same application. In other words, if we should allow the same application to use both stateless and stateful versions of the Identity bean. The use case that may justify that is when your services could support both JSF and HTML5 clients, where the latter do not use the JSESSIONID to track user session but a specific token. > > Any thoughts ? > > [1] https://issues.jboss.org/browse/PLINK-400 > > Regards. > Pedro Igor From psilva at redhat.com Tue Apr 1 10:24:04 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 1 Apr 2014 10:24:04 -0400 (EDT) Subject: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean In-Reply-To: <533ABB3A.7030603@redhat.com> References: <367285324.5598398.1396321062597.JavaMail.zimbra@redhat.com> <533ABB3A.7030603@redhat.com> Message-ID: <1736655349.5804218.1396362244647.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Anil Saldhana" > To: security-dev at lists.jboss.org > Sent: Tuesday, April 1, 2014 10:12:26 AM > Subject: Re: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean > > Pedro, > > - how does the programmer figure out he is using the Identity bean in a > stateless scope and other usage: session scope? They can do that using a qualifier, an alternative or even a stereotype. Regarding the solution, it should be very clear which scope he is using. The decision about supporting both scopes or not from the same application is important to define what is the best solution. > - will it add complexity to the internal implementation? I don't think so. It should not bring any complexity to the implementation or API usage. > > Regards, > Anil > > On 03/31/2014 09:57 PM, Pedro Igor Silva wrote: > > Hi All, > > > > Shane and I had a discussion today about PLINK-400 [1]. Which is > > basically about adding a stateless behavior to the Identity bean. > > > > Today the Identity bean is session scoped, which implies that an > > authenticated user has a corresponding session on the server. That is > > fine when you're using JSF as view technology and the JESSIONID > > cookie is used to track user session. Or even using HTML5 and JS from > > a browser. The point here is that you don't need to send anything > > special in order to know that a specific request came from an > > previously authenticated user. The cookie is always sent to and from > > the server. > > > > Recently, after some discussions about making PL even more suitable > > for mobile, we decided to add a stateless behavior to the Identity > > bean. Basically, instead of creating a session on the server for each > > authenticated user, we don't store anything. Every data consumed and > > produced during the authentication process is destroyed once the > > request is finished. This is a very important requirement when you > > don't want to consume server resources with users sessions, specially > > if you're writing a RESTful API. Another example is Anil's work to > > integrate Apache Camel with PL. > > > > Usually, those use cases are based on a token which is issued after a > > successful authentication. Subsequent calls to protected services > > will then require the token to be validated in order to know if the > > request is from an authenticated user or not. Or even check if the > > token is still valid, etc. > > > > We're pretty sure about adding this stateless nature to the Identity > > bean. But we would like to know from you if we should also support > > both "natures" from the same application. In other words, if we > > should allow the same application to use both stateless and stateful > > versions of the Identity bean. The use case that may justify that is > > when your services could support both JSF and HTML5 clients, where > > the latter do not use the JSESSIONID to track user session but a > > specific token. > > > > Any thoughts ? > > > > [1] https://issues.jboss.org/browse/PLINK-400 > > > > Regards. > > Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > From Anil.Saldhana at redhat.com Tue Apr 1 10:27:46 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Tue, 01 Apr 2014 09:27:46 -0500 Subject: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean In-Reply-To: <1736655349.5804218.1396362244647.JavaMail.zimbra@redhat.com> References: <367285324.5598398.1396321062597.JavaMail.zimbra@redhat.com> <533ABB3A.7030603@redhat.com> <1736655349.5804218.1396362244647.JavaMail.zimbra@redhat.com> Message-ID: <533ACCE2.8010701@redhat.com> On 04/01/2014 09:24 AM, Pedro Igor Silva wrote: > ----- Original Message ----- >> From: "Anil Saldhana" >> To: security-dev at lists.jboss.org >> Sent: Tuesday, April 1, 2014 10:12:26 AM >> Subject: Re: [security-dev] [PLINK-400] - Stateless Nature of the Identity Bean >> >> Pedro, >> >> - how does the programmer figure out he is using the Identity bean in a >> stateless scope and other usage: session scope? > They can do that using a qualifier, an alternative or even a stereotype. Regarding the solution, it should be very clear which scope he is using. > The decision about supporting both scopes or not from the same application is important to define what is the best solution. > >> - will it add complexity to the internal implementation? > I don't think so. It should not bring any complexity to the implementation or API usage. Then it should be fine as long as we have proper documentation on usage patterns. :) >> Regards, >> Anil >> >> On 03/31/2014 09:57 PM, Pedro Igor Silva wrote: >>> Hi All, >>> >>> Shane and I had a discussion today about PLINK-400 [1]. Which is >>> basically about adding a stateless behavior to the Identity bean. >>> >>> Today the Identity bean is session scoped, which implies that an >>> authenticated user has a corresponding session on the server. That is >>> fine when you're using JSF as view technology and the JESSIONID >>> cookie is used to track user session. Or even using HTML5 and JS from >>> a browser. The point here is that you don't need to send anything >>> special in order to know that a specific request came from an >>> previously authenticated user. The cookie is always sent to and from >>> the server. >>> >>> Recently, after some discussions about making PL even more suitable >>> for mobile, we decided to add a stateless behavior to the Identity >>> bean. Basically, instead of creating a session on the server for each >>> authenticated user, we don't store anything. Every data consumed and >>> produced during the authentication process is destroyed once the >>> request is finished. This is a very important requirement when you >>> don't want to consume server resources with users sessions, specially >>> if you're writing a RESTful API. Another example is Anil's work to >>> integrate Apache Camel with PL. >>> >>> Usually, those use cases are based on a token which is issued after a >>> successful authentication. Subsequent calls to protected services >>> will then require the token to be validated in order to know if the >>> request is from an authenticated user or not. Or even check if the >>> token is still valid, etc. >>> >>> We're pretty sure about adding this stateless nature to the Identity >>> bean. But we would like to know from you if we should also support >>> both "natures" from the same application. In other words, if we >>> should allow the same application to use both stateless and stateful >>> versions of the Identity bean. The use case that may justify that is >>> when your services could support both JSF and HTML5 clients, where >>> the latter do not use the JSESSIONID to track user session but a >>> specific token. >>> >>> Any thoughts ? >>> >>> [1] https://issues.jboss.org/browse/PLINK-400 >>> >>> Regards. >>> Pedro Igor >> From lightguard.jp at gmail.com Tue Apr 1 10:47:41 2014 From: lightguard.jp at gmail.com (Jason Porter) Date: Tue, 1 Apr 2014 08:47:41 -0600 Subject: [security-dev] Security Interceptors in Java EE8 In-Reply-To: <533ABAFC.3040108@redhat.com> References: <533A1684.4070704@redhat.com> <533ABAFC.3040108@redhat.com> Message-ID: +1 Very good idea. You could also piggy back on the survey and show people that we already have something that will more than likely be very close to what will be the standard, today :) On Tue, Apr 1, 2014 at 7:11 AM, Anil Saldhana wrote: > The survey item says: > "Support for CDI based security interceptor for authorization decisions". > > Deltaspike influence. :) > > Pedro and I were discussing yesterday that it may be good to put up a > PicketLink > blog post on the website talking about how PL is simplifying security > and showcase > our quickstarts for the security interceptor. > > On 03/31/2014 08:29 PM, Shane Bryzak wrote: > > Looks like security interceptors was a popular feature request for Java > > EE8. Something we should probably get involved with I think? > > > > https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > -- Jason Porter http://en.gravatar.com/lightguardjp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140401/b1feee09/attachment.html From psilva at redhat.com Tue Apr 1 11:11:15 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 1 Apr 2014 11:11:15 -0400 (EDT) Subject: [security-dev] Security Interceptors in Java EE8 In-Reply-To: <533ABAFC.3040108@redhat.com> References: <533A1684.4070704@redhat.com> <533ABAFC.3040108@redhat.com> Message-ID: <1177877328.5844199.1396365075497.JavaMail.zimbra@redhat.com> Agree. But as you said, the authz part (using security annotations) is provided by DS today. We had a pretty similar discussion in another thread about PL and WFK :) ----- Original Message ----- From: "Anil Saldhana" To: security-dev at lists.jboss.org Sent: Tuesday, April 1, 2014 10:11:24 AM Subject: Re: [security-dev] Security Interceptors in Java EE8 The survey item says: "Support for CDI based security interceptor for authorization decisions". Deltaspike influence. :) Pedro and I were discussing yesterday that it may be good to put up a PicketLink blog post on the website talking about how PL is simplifying security and showcase our quickstarts for the security interceptor. On 03/31/2014 08:29 PM, Shane Bryzak wrote: > Looks like security interceptors was a popular feature request for Java > EE8. Something we should probably get involved with I think? > > https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee _______________________________________________ security-dev mailing list security-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev From david.lloyd at redhat.com Tue Apr 1 11:48:20 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 01 Apr 2014 10:48:20 -0500 Subject: [security-dev] Security Interceptors in Java EE8 In-Reply-To: <533A1684.4070704@redhat.com> References: <533A1684.4070704@redhat.com> Message-ID: <533ADFC4.9030307@redhat.com> On 03/31/2014 08:29 PM, Shane Bryzak wrote: > Looks like security interceptors was a popular feature request for Java > EE8. Something we should probably get involved with I think? > > https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee I absolutely intend to get involved in this one as soon as the EG is established. -- - DML From psilva at redhat.com Thu Apr 10 10:07:30 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 10 Apr 2014 10:07:30 -0400 (EDT) Subject: [security-dev] JS libraries for crypto and signatures In-Reply-To: <1682214575.2764338.1397138671759.JavaMail.zimbra@redhat.com> Message-ID: <306820833.2766351.1397138850644.JavaMail.zimbra@redhat.com> Hi, Have you ever looked/used these JS libraries for crypto and signature ? https://github.com/kjur/jsrsasign I did some signatures tests and it seems to work fine. Wondering if someone have used it for real ... Regards. Pedro Igor From Anil.Saldhana at redhat.com Thu Apr 10 10:44:57 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 10 Apr 2014 09:44:57 -0500 Subject: [security-dev] JS libraries for crypto and signatures In-Reply-To: <306820833.2766351.1397138850644.JavaMail.zimbra@redhat.com> References: <306820833.2766351.1397138850644.JavaMail.zimbra@redhat.com> Message-ID: <5346AE69.4020901@redhat.com> An important topic. Until the W3C Web Cryptographic Group (http://www.w3.org/2011/11/webcryptography-charter.html) finalizes its standard and we have conforming implementations, the question of trustworthy implementations cannot be really answered. If the JS library is just implementing signature or crypto algorithms and you have tested it, may be you should go for it. The situation is very similar to the following: - JSON processing (Until JSON-P JSR https://jcp.org/en/jsr/detail?id=353 was finalized, we could go either with Jackson or other json library) - Captcha libraries (there are many) Your application has to choose one and go forward. On 04/10/2014 09:07 AM, Pedro Igor Silva wrote: > Hi, > > Have you ever looked/used these JS libraries for crypto and signature ? > > https://github.com/kjur/jsrsasign > > I did some signatures tests and it seems to work fine. Wondering if someone have used it for real ... > > Regards. > Pedro Igor From bburke at redhat.com Thu Apr 10 22:58:18 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 10 Apr 2014 22:58:18 -0400 Subject: [security-dev] JS libraries for crypto and signatures In-Reply-To: <5346AE69.4020901@redhat.com> References: <306820833.2766351.1397138850644.JavaMail.zimbra@redhat.com> <5346AE69.4020901@redhat.com> Message-ID: <53475A4A.9020007@redhat.com> Know any javascript libs for JSE/JWS? On 4/10/2014 10:44 AM, Anil Saldhana wrote: > An important topic. > > Until the W3C Web Cryptographic Group > (http://www.w3.org/2011/11/webcryptography-charter.html) > finalizes its standard and we have conforming implementations, > the question of trustworthy implementations cannot be really answered. > > If the JS library is just implementing signature or crypto algorithms > and you have tested it, may be you > should go for it. > > The situation is very similar to the following: > - JSON processing (Until JSON-P JSR https://jcp.org/en/jsr/detail?id=353 > was finalized, we could go either with Jackson or other json library) > - Captcha libraries (there are many) > > Your application has to choose one and go forward. > > On 04/10/2014 09:07 AM, Pedro Igor Silva wrote: >> Hi, >> >> Have you ever looked/used these JS libraries for crypto and signature ? >> >> https://github.com/kjur/jsrsasign >> >> I did some signatures tests and it seems to work fine. Wondering if someone have used it for real ... >> >> Regards. >> Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From Anil.Saldhana at redhat.com Thu Apr 10 11:00:22 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 10 Apr 2014 10:00:22 -0500 Subject: [security-dev] JS libraries for crypto and signatures In-Reply-To: <53475A4A.9020007@redhat.com> References: <306820833.2766351.1397138850644.JavaMail.zimbra@redhat.com> <5346AE69.4020901@redhat.com> <53475A4A.9020007@redhat.com> Message-ID: <5346B206.2060008@redhat.com> The Javascript section of http://openid.net/developers/libraries/ lists some. On 04/10/2014 09:58 PM, Bill Burke wrote: > Know any javascript libs for JSE/JWS? > > On 4/10/2014 10:44 AM, Anil Saldhana wrote: >> An important topic. >> >> Until the W3C Web Cryptographic Group >> (http://www.w3.org/2011/11/webcryptography-charter.html) >> finalizes its standard and we have conforming implementations, >> the question of trustworthy implementations cannot be really answered. >> >> If the JS library is just implementing signature or crypto algorithms >> and you have tested it, may be you >> should go for it. >> >> The situation is very similar to the following: >> - JSON processing (Until JSON-P JSR https://jcp.org/en/jsr/detail?id=353 >> was finalized, we could go either with Jackson or other json library) >> - Captcha libraries (there are many) >> >> Your application has to choose one and go forward. >> >> On 04/10/2014 09:07 AM, Pedro Igor Silva wrote: >>> Hi, >>> >>> Have you ever looked/used these JS libraries for crypto and signature ? >>> >>> https://github.com/kjur/jsrsasign >>> >>> I did some signatures tests and it seems to work fine. Wondering if someone have used it for real ... >>> >>> Regards. >>> Pedro Igor >>> From psilva at redhat.com Thu Apr 10 12:06:00 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 10 Apr 2014 12:06:00 -0400 (EDT) Subject: [security-dev] JS libraries for crypto and signatures In-Reply-To: <53475A4A.9020007@redhat.com> References: <306820833.2766351.1397138850644.JavaMail.zimbra@redhat.com> <5346AE69.4020901@redhat.com> <53475A4A.9020007@redhat.com> Message-ID: <1870474951.2851971.1397145960286.JavaMail.zimbra@redhat.com> Found this too: https://github.com/michaelrhanson/jwt-js ----- Original Message ----- From: "Bill Burke" To: security-dev at lists.jboss.org Sent: Thursday, April 10, 2014 11:58:18 PM Subject: Re: [security-dev] JS libraries for crypto and signatures Know any javascript libs for JSE/JWS? On 4/10/2014 10:44 AM, Anil Saldhana wrote: > An important topic. > > Until the W3C Web Cryptographic Group > (http://www.w3.org/2011/11/webcryptography-charter.html) > finalizes its standard and we have conforming implementations, > the question of trustworthy implementations cannot be really answered. > > If the JS library is just implementing signature or crypto algorithms > and you have tested it, may be you > should go for it. > > The situation is very similar to the following: > - JSON processing (Until JSON-P JSR https://jcp.org/en/jsr/detail?id=353 > was finalized, we could go either with Jackson or other json library) > - Captcha libraries (there are many) > > Your application has to choose one and go forward. > > On 04/10/2014 09:07 AM, Pedro Igor Silva wrote: >> Hi, >> >> Have you ever looked/used these JS libraries for crypto and signature ? >> >> https://github.com/kjur/jsrsasign >> >> I did some signatures tests and it seems to work fine. Wondering if someone have used it for real ... >> >> Regards. >> Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev From bruno at abstractj.org Mon Apr 14 13:51:19 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 14 Apr 2014 14:51:19 -0300 Subject: [security-dev] Vault to store sensitive data Message-ID: <534C2017.3000309@abstractj.org> Good morning, I would like to know if Vaults from PicketBox are specific for datasources or any kind of sensitive data. I would like to store a key material, used for encryption and not sure if this is the correct configuration for it: - standalone.xml This is the stack trace when Wildfly is initialized: https://gist.github.com/abstractj/4542c7cf1aa8a36ebad9. I would appreciate any pointers to the documentation. -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/security-dev/attachments/20140414/b29a76cb/attachment.bin From asaldhan at redhat.com Mon Apr 14 14:43:06 2014 From: asaldhan at redhat.com (Anil Saldhana) Date: Mon, 14 Apr 2014 14:43:06 -0400 (EDT) Subject: [security-dev] Vault to store sensitive data In-Reply-To: <534C2017.3000309@abstractj.org> References: <534C2017.3000309@abstractj.org> Message-ID: <751F1FE5-582D-478A-9EE5-E09203642BB3@redhat.com> The system properties functionality in WildFly may not be ready to take vault expressions. I remember seeing a JIRA issue for that. Could you take a look at the WFLY JIRA (as I am at an airport and will take time to dig the issue)? Vault can be used for any sensitive data. > On Apr 14, 2014, at 12:51 PM, Bruno Oliveira wrote: > > Good morning, I would like to know if Vaults from PicketBox are specific > for datasources or any kind of sensitive data. I would like to store a > key material, used for encryption and not sure if this is the correct > configuration for it: > > - standalone.xml > > > value="${VAULT::ds_SecurityVaultDS::password::2DyuLAae8wP.pSsrT/gGhn}"/> > > > > > value="/servers/wildfly-current/vault/vault.keystore"/> > value="MASK-2DyuLAae8wP.pSsrT/gGhn"/> > > > > value="/servers/wildfly-current/vault/"/> > > > This is the stack trace when Wildfly is initialized: > https://gist.github.com/abstractj/4542c7cf1aa8a36ebad9. I would > appreciate any pointers to the documentation. > > -- > abstractj > > > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From bruno at abstractj.org Mon Apr 14 15:52:52 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 14 Apr 2014 16:52:52 -0300 Subject: [security-dev] Vault to store sensitive data In-Reply-To: <751F1FE5-582D-478A-9EE5-E09203642BB3@redhat.com> References: <534C2017.3000309@abstractj.org> <751F1FE5-582D-478A-9EE5-E09203642BB3@redhat.com> Message-ID: Sure, np. Thank you Anil On Mon, Apr 14, 2014 at 3:43 PM, Anil Saldhana wrote: > The system properties functionality in WildFly may not be ready to take > vault expressions. I remember seeing a JIRA issue for that. Could you take > a look at the WFLY JIRA (as I am at an airport and will take time to dig > the issue)? > > Vault can be used for any sensitive data. > > > On Apr 14, 2014, at 12:51 PM, Bruno Oliveira > wrote: > > > > Good morning, I would like to know if Vaults from PicketBox are specific > > for datasources or any kind of sensitive data. I would like to store a > > key material, used for encryption and not sure if this is the correct > > configuration for it: > > > > - standalone.xml > > > > > > > value="${VAULT::ds_SecurityVaultDS::password::2DyuLAae8wP.pSsrT/gGhn}"/> > > > > > > > > > > > value="/servers/wildfly-current/vault/vault.keystore"/> > > > value="MASK-2DyuLAae8wP.pSsrT/gGhn"/> > > > > > > > > > value="/servers/wildfly-current/vault/"/> > > > > > > This is the stack trace when Wildfly is initialized: > > https://gist.github.com/abstractj/4542c7cf1aa8a36ebad9. I would > > appreciate any pointers to the documentation. > > > > -- > > abstractj > > > > > > _______________________________________________ > > security-dev mailing list > > security-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/security-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140414/0041e5fe/attachment.html From sguilhen at redhat.com Mon Apr 14 16:15:47 2014 From: sguilhen at redhat.com (Stefan Guilhen) Date: Mon, 14 Apr 2014 17:15:47 -0300 Subject: [security-dev] Vault to store sensitive data In-Reply-To: <751F1FE5-582D-478A-9EE5-E09203642BB3@redhat.com> References: <534C2017.3000309@abstractj.org> <751F1FE5-582D-478A-9EE5-E09203642BB3@redhat.com> Message-ID: <534C41F3.5000608@redhat.com> I believe this is the jira Anil is talking about https://issues.jboss.org/browse/WFLY-1904 - its been fixed for WF 8.0.0.CR1. On 04/14/2014 03:43 PM, Anil Saldhana wrote: > The system properties functionality in WildFly may not be ready to take vault expressions. I remember seeing a JIRA issue for that. Could you take a look at the WFLY JIRA (as I am at an airport and will take time to dig the issue)? > > Vault can be used for any sensitive data. > >> On Apr 14, 2014, at 12:51 PM, Bruno Oliveira wrote: >> >> Good morning, I would like to know if Vaults from PicketBox are specific >> for datasources or any kind of sensitive data. I would like to store a >> key material, used for encryption and not sure if this is the correct >> configuration for it: >> >> - standalone.xml >> >> >> > value="${VAULT::ds_SecurityVaultDS::password::2DyuLAae8wP.pSsrT/gGhn}"/> >> >> >> >> >> > value="/servers/wildfly-current/vault/vault.keystore"/> >> > value="MASK-2DyuLAae8wP.pSsrT/gGhn"/> >> >> >> >> > value="/servers/wildfly-current/vault/"/> >> >> >> This is the stack trace when Wildfly is initialized: >> https://gist.github.com/abstractj/4542c7cf1aa8a36ebad9. I would >> appreciate any pointers to the documentation. >> >> -- >> abstractj >> >> >> _______________________________________________ >> security-dev mailing list >> security-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From sdouglas at redhat.com Mon Apr 14 16:25:10 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 15 Apr 2014 06:25:10 +1000 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <52E13D2D.3010702@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> Message-ID: <534C4426.3070001@redhat.com> Do you guys have any update on the time frame for this? Stuart Anil Saldhana wrote: > https://github.com/picketbox/picketbox-container > > This has been there for a few months now. I am trying to dodge my > memory as to why we did not use it to > upgrade in WF8. Maybe Stefan remembers. > > I guess it was something to do with the plan to discard very old code > and refactor it to just include what is necessary for WF. > I think we did not have enough time to go with the plan yet. > > Definitely will be the PBox repo in WF9+. > > > On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >> +1 Please make the move - getting it moved is a one off task and once >> moved it is one less project we need SVN for ;-) >> >> >> On 23/01/14 13:14, Stuart Douglas wrote: >>> Hi, >>> >>> Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. >>> >>> Stuart >>> > > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From asaldhan at redhat.com Mon Apr 14 21:26:30 2014 From: asaldhan at redhat.com (Anil Saldhana) Date: Mon, 14 Apr 2014 21:26:30 -0400 (EDT) Subject: [security-dev] Moving picketbox to Github In-Reply-To: <534C4426.3070001@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> <534C4426.3070001@redhat.com> Message-ID: <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> Next week for sure. > On Apr 14, 2014, at 1:25 PM, Stuart Douglas wrote: > > Do you guys have any update on the time frame for this? > > Stuart > > Anil Saldhana wrote: >> https://github.com/picketbox/picketbox-container >> >> This has been there for a few months now. I am trying to dodge my >> memory as to why we did not use it to >> upgrade in WF8. Maybe Stefan remembers. >> >> I guess it was something to do with the plan to discard very old code >> and refactor it to just include what is necessary for WF. >> I think we did not have enough time to go with the plan yet. >> >> Definitely will be the PBox repo in WF9+. >> >> >>> On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >>> +1 Please make the move - getting it moved is a one off task and once >>> moved it is one less project we need SVN for ;-) >>> >>> >>>> On 23/01/14 13:14, Stuart Douglas wrote: >>>> Hi, >>>> >>>> Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. >>>> >>>> Stuart >> >> _______________________________________________ >> security-dev mailing list >> security-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From bruno at abstractj.org Wed Apr 16 00:42:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Apr 2014 01:42:21 -0300 Subject: [security-dev] Vault to store sensitive data In-Reply-To: <534C41F3.5000608@redhat.com> References: <534C2017.3000309@abstractj.org> <751F1FE5-582D-478A-9EE5-E09203642BB3@redhat.com> <534C41F3.5000608@redhat.com> Message-ID: <534E0A2D.4010903@abstractj.org> Thank you Stefan > Stefan Guilhen > April 14, 2014 at 5:15 PM > I believe this is the jira Anil is talking about > https://issues.jboss.org/browse/WFLY-1904 - its been fixed for WF > 8.0.0.CR1. > > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev -- abstractj -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/security-dev/attachments/20140416/b2008781/attachment.bin From psilva at redhat.com Thu Apr 17 02:41:54 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 17 Apr 2014 02:41:54 -0400 (EDT) Subject: [security-dev] [Release] PicketLink 2.6.0.CR2 In-Reply-To: <42332375.5859519.1397716180658.JavaMail.zimbra@redhat.com> Message-ID: <328489296.5863804.1397716914967.JavaMail.zimbra@redhat.com> Hi All, The PicketLink team is pleased to announce the release of v2.6.0.CR2. Special thanks to Marek Posolda for all contribution and feedback regarding the LDAP store. For more details, take a look at our site[1]. [1] http://picketlink.org/news/2014/04/17/Release-2/ Regards. Pedro Igor From mposolda at redhat.com Fri Apr 18 02:24:12 2014 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 18 Apr 2014 08:24:12 +0200 Subject: [security-dev] [Release] PicketLink 2.6.0.CR2 In-Reply-To: <328489296.5863804.1397716914967.JavaMail.zimbra@redhat.com> References: <328489296.5863804.1397716914967.JavaMail.zimbra@redhat.com> Message-ID: <5350C50C.8070202@redhat.com> Great news! Thanks to you as well for all the LDAP fixes. Marek On 17.4.2014 08:41, Pedro Igor Silva wrote: > Hi All, > > The PicketLink team is pleased to announce the release of v2.6.0.CR2. > > Special thanks to Marek Posolda for all contribution and feedback regarding the LDAP store. > > For more details, take a look at our site[1]. > > [1] http://picketlink.org/news/2014/04/17/Release-2/ > > Regards. > Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From asaldhan at redhat.com Fri Apr 18 10:29:42 2014 From: asaldhan at redhat.com (Anil Saldhana) Date: Fri, 18 Apr 2014 10:29:42 -0400 (EDT) Subject: [security-dev] [Release] PicketLink 2.6.0.CR2 In-Reply-To: <5350C50C.8070202@redhat.com> References: <328489296.5863804.1397716914967.JavaMail.zimbra@redhat.com> <5350C50C.8070202@redhat.com> Message-ID: <6D1C26D5-CDC8-43AD-BE8A-82F23AA7F625@redhat.com> Now on to notify users on social media about CR2. Good progress. > On Apr 18, 2014, at 1:24 AM, Marek Posolda wrote: > > Great news! Thanks to you as well for all the LDAP fixes. > > Marek > >> On 17.4.2014 08:41, Pedro Igor Silva wrote: >> Hi All, >> >> The PicketLink team is pleased to announce the release of v2.6.0.CR2. >> >> Special thanks to Marek Posolda for all contribution and feedback regarding the LDAP store. >> >> For more details, take a look at our site[1]. >> >> [1] http://picketlink.org/news/2014/04/17/Release-2/ >> >> Regards. >> Pedro Igor >> _______________________________________________ >> security-dev mailing list >> security-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev > > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From Anil.Saldhana at redhat.com Thu Apr 24 15:29:29 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 24 Apr 2014 14:29:29 -0500 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> <534C4426.3070001@redhat.com> <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> Message-ID: <53596619.7030404@redhat.com> Here is the github workspace after migration https://github.com/picketbox/picketbox This workspace is to be used exclusively for WildFly. Eventually, I think we should bump the version to PicketBox 6.x for WildFly9+ (Stefan can make the call) (PicketBox 5 was an intermediate effort at Java SE security framework which eventually got consolidated in PicketLink). On 04/14/2014 08:26 PM, Anil Saldhana wrote: > Next week for sure. > >> On Apr 14, 2014, at 1:25 PM, Stuart Douglas wrote: >> >> Do you guys have any update on the time frame for this? >> >> Stuart >> >> Anil Saldhana wrote: >>> https://github.com/picketbox/picketbox-container >>> >>> This has been there for a few months now. I am trying to dodge my >>> memory as to why we did not use it to >>> upgrade in WF8. Maybe Stefan remembers. >>> >>> I guess it was something to do with the plan to discard very old code >>> and refactor it to just include what is necessary for WF. >>> I think we did not have enough time to go with the plan yet. >>> >>> Definitely will be the PBox repo in WF9+. >>> >>> >>>> On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >>>> +1 Please make the move - getting it moved is a one off task and once >>>> moved it is one less project we need SVN for ;-) >>>> >>>> >>>>> On 23/01/14 13:14, Stuart Douglas wrote: >>>>> Hi, >>>>> >>>>> Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. >>>>> >>>>> Stuart >>>>> From sdouglas at redhat.com Thu Apr 24 15:31:19 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 24 Apr 2014 12:31:19 -0700 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <53596619.7030404@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> <534C4426.3070001@redhat.com> <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> <53596619.7030404@redhat.com> Message-ID: <53596687.8020204@redhat.com> So is the old SVN repo still going to be used for EAP 6 related work? If so why, as it will mean patches have to be applied in two different systems. Stuart Anil Saldhana wrote: > Here is the github workspace after migration > https://github.com/picketbox/picketbox > > This workspace is to be used exclusively for WildFly. > > Eventually, I think we should bump the version to PicketBox 6.x for > WildFly9+ (Stefan can make the call) > > (PicketBox 5 was an intermediate effort at Java SE security framework > which eventually got consolidated in PicketLink). > > > On 04/14/2014 08:26 PM, Anil Saldhana wrote: >> Next week for sure. >> >>> On Apr 14, 2014, at 1:25 PM, Stuart Douglas wrote: >>> >>> Do you guys have any update on the time frame for this? >>> >>> Stuart >>> >>> Anil Saldhana wrote: >>>> https://github.com/picketbox/picketbox-container >>>> >>>> This has been there for a few months now. I am trying to dodge my >>>> memory as to why we did not use it to >>>> upgrade in WF8. Maybe Stefan remembers. >>>> >>>> I guess it was something to do with the plan to discard very old code >>>> and refactor it to just include what is necessary for WF. >>>> I think we did not have enough time to go with the plan yet. >>>> >>>> Definitely will be the PBox repo in WF9+. >>>> >>>> >>>>> On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >>>>> +1 Please make the move - getting it moved is a one off task and once >>>>> moved it is one less project we need SVN for ;-) >>>>> >>>>> >>>>>> On 23/01/14 13:14, Stuart Douglas wrote: >>>>>> Hi, >>>>>> >>>>>> Are there any plans to move Picketbox to github? It makes it much >>>>>> easer for people outside the security team to submit fixes etc. >>>>>> >>>>>> Stuart >>>>>> From Anil.Saldhana at redhat.com Thu Apr 24 17:20:52 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 24 Apr 2014 16:20:52 -0500 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <53596687.8020204@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> <534C4426.3070001@redhat.com> <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> <53596619.7030404@redhat.com> <53596687.8020204@redhat.com> Message-ID: <53598034.8010901@redhat.com> Stuart, the svn git migration process was choking on some branches of PicketBox SVN. So I did not migrate the branches over. Just the trunk and tags. I will try to do this entire process again with just migrating to recent branches. :( Regards, Anil On 04/24/2014 02:31 PM, Stuart Douglas wrote: > So is the old SVN repo still going to be used for EAP 6 related work? If > so why, as it will mean patches have to be applied in two different > systems. > > Stuart > > Anil Saldhana wrote: >> Here is the github workspace after migration >> https://github.com/picketbox/picketbox >> >> This workspace is to be used exclusively for WildFly. >> >> Eventually, I think we should bump the version to PicketBox 6.x for >> WildFly9+ (Stefan can make the call) >> >> (PicketBox 5 was an intermediate effort at Java SE security framework >> which eventually got consolidated in PicketLink). >> >> >> On 04/14/2014 08:26 PM, Anil Saldhana wrote: >>> Next week for sure. >>> >>>> On Apr 14, 2014, at 1:25 PM, Stuart Douglas wrote: >>>> >>>> Do you guys have any update on the time frame for this? >>>> >>>> Stuart >>>> >>>> Anil Saldhana wrote: >>>>> https://github.com/picketbox/picketbox-container >>>>> >>>>> This has been there for a few months now. I am trying to dodge my >>>>> memory as to why we did not use it to >>>>> upgrade in WF8. Maybe Stefan remembers. >>>>> >>>>> I guess it was something to do with the plan to discard very old code >>>>> and refactor it to just include what is necessary for WF. >>>>> I think we did not have enough time to go with the plan yet. >>>>> >>>>> Definitely will be the PBox repo in WF9+. >>>>> >>>>> >>>>>> On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >>>>>> +1 Please make the move - getting it moved is a one off task and once >>>>>> moved it is one less project we need SVN for ;-) >>>>>> >>>>>> >>>>>>> On 23/01/14 13:14, Stuart Douglas wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Are there any plans to move Picketbox to github? It makes it much >>>>>>> easer for people outside the security team to submit fixes etc. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> From Anil.Saldhana at redhat.com Thu Apr 24 18:49:23 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 24 Apr 2014 17:49:23 -0500 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <53598034.8010901@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> <534C4426.3070001@redhat.com> <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> <53596619.7030404@redhat.com> <53596687.8020204@redhat.com> <53598034.8010901@redhat.com> Message-ID: <535994F3.2040506@redhat.com> https://github.com/picketbox/picketbox I pushed all branches and tags. So I think this is an exact replica of the svn repository. Process followed is in gist: https://gist.github.com/anilsaldhana/11271541 On 04/24/2014 04:20 PM, Anil Saldhana wrote: > Stuart, > the svn git migration process was choking on some branches of > PicketBox SVN. > So I did not migrate the branches over. Just the trunk and tags. > > I will try to do this entire process again with just migrating to recent > branches. :( > > Regards, > Anil > > On 04/24/2014 02:31 PM, Stuart Douglas wrote: >> So is the old SVN repo still going to be used for EAP 6 related work? If >> so why, as it will mean patches have to be applied in two different >> systems. >> >> Stuart >> >> Anil Saldhana wrote: >>> Here is the github workspace after migration >>> https://github.com/picketbox/picketbox >>> >>> This workspace is to be used exclusively for WildFly. >>> >>> Eventually, I think we should bump the version to PicketBox 6.x for >>> WildFly9+ (Stefan can make the call) >>> >>> (PicketBox 5 was an intermediate effort at Java SE security framework >>> which eventually got consolidated in PicketLink). >>> >>> >>> On 04/14/2014 08:26 PM, Anil Saldhana wrote: >>>> Next week for sure. >>>> >>>>> On Apr 14, 2014, at 1:25 PM, Stuart Douglas wrote: >>>>> >>>>> Do you guys have any update on the time frame for this? >>>>> >>>>> Stuart >>>>> >>>>> Anil Saldhana wrote: >>>>>> https://github.com/picketbox/picketbox-container >>>>>> >>>>>> This has been there for a few months now. I am trying to dodge my >>>>>> memory as to why we did not use it to >>>>>> upgrade in WF8. Maybe Stefan remembers. >>>>>> >>>>>> I guess it was something to do with the plan to discard very old code >>>>>> and refactor it to just include what is necessary for WF. >>>>>> I think we did not have enough time to go with the plan yet. >>>>>> >>>>>> Definitely will be the PBox repo in WF9+. >>>>>> >>>>>> >>>>>>> On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >>>>>>> +1 Please make the move - getting it moved is a one off task and once >>>>>>> moved it is one less project we need SVN for ;-) >>>>>>> >>>>>>> >>>>>>>> On 23/01/14 13:14, Stuart Douglas wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Are there any plans to move Picketbox to github? It makes it much >>>>>>>> easer for people outside the security team to submit fixes etc. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> >>>>>>>> From Anil.Saldhana at redhat.com Fri Apr 25 13:36:08 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 25 Apr 2014 12:36:08 -0500 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <535994F3.2040506@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> <534C4426.3070001@redhat.com> <16BA1AB7-28DB-4E96-91CC-A668B2EDA3C6@redhat.com> <53596619.7030404@redhat.com> <53596687.8020204@redhat.com> <53598034.8010901@redhat.com> <535994F3.2040506@redhat.com> Message-ID: <535A9D08.9040301@redhat.com> On 04/24/2014 05:49 PM, Anil Saldhana wrote: > https://github.com/picketbox/picketbox > > I pushed all branches and tags. So I think this is an exact replica of > the svn repository. > > > Process followed is in gist: https://gist.github.com/anilsaldhana/11271541 Additionally, made the svn read only. > > > On 04/24/2014 04:20 PM, Anil Saldhana wrote: >> Stuart, >> the svn git migration process was choking on some branches of >> PicketBox SVN. >> So I did not migrate the branches over. Just the trunk and tags. >> >> I will try to do this entire process again with just migrating to recent >> branches. :( >> >> Regards, >> Anil >> >> On 04/24/2014 02:31 PM, Stuart Douglas wrote: >>> So is the old SVN repo still going to be used for EAP 6 related work? If >>> so why, as it will mean patches have to be applied in two different >>> systems. >>> >>> Stuart >>> >>> Anil Saldhana wrote: >>>> Here is the github workspace after migration >>>> https://github.com/picketbox/picketbox >>>> >>>> This workspace is to be used exclusively for WildFly. >>>> >>>> Eventually, I think we should bump the version to PicketBox 6.x for >>>> WildFly9+ (Stefan can make the call) >>>> >>>> (PicketBox 5 was an intermediate effort at Java SE security framework >>>> which eventually got consolidated in PicketLink). >>>> >>>> >>>> On 04/14/2014 08:26 PM, Anil Saldhana wrote: >>>>> Next week for sure. >>>>> >>>>>> On Apr 14, 2014, at 1:25 PM, Stuart Douglas wrote: >>>>>> >>>>>> Do you guys have any update on the time frame for this? >>>>>> >>>>>> Stuart >>>>>> >>>>>> Anil Saldhana wrote: >>>>>>> https://github.com/picketbox/picketbox-container >>>>>>> >>>>>>> This has been there for a few months now. I am trying to dodge my >>>>>>> memory as to why we did not use it to >>>>>>> upgrade in WF8. Maybe Stefan remembers. >>>>>>> >>>>>>> I guess it was something to do with the plan to discard very old code >>>>>>> and refactor it to just include what is necessary for WF. >>>>>>> I think we did not have enough time to go with the plan yet. >>>>>>> >>>>>>> Definitely will be the PBox repo in WF9+. >>>>>>> >>>>>>> >>>>>>>> On 01/23/2014 09:14 AM, Darran Lofthouse wrote: >>>>>>>> +1 Please make the move - getting it moved is a one off task and once >>>>>>>> moved it is one less project we need SVN for ;-) >>>>>>>> >>>>>>>> >>>>>>>>> On 23/01/14 13:14, Stuart Douglas wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Are there any plans to move Picketbox to github? It makes it much >>>>>>>>> easer for people outside the security team to submit fixes etc. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>