wonky jenkins
Hi! Currently our Jenkins is a bit wonky/wacky. Currently clarifying the issue with infra. LieGrue, strub
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684587#comment-13684587 ] Mark Struberg commented on DELTASPIKE-382: -- Logging the configured values is something all my operations guy ever wanted. I don't agree with the X libs argument. If those other X libs read deltaspike configuration, well then that's up to them... In practice there is NO way to hide this info from code which is running on your server. Well you could activate the SecurityManager, but then 99% of all apps would even refuse to start... It doesn't care at all whether you have it store symmetrically encrypted or not. At some point in time you need to uncrypt it. End then you have all the pwd in plaintext as well. Once again: the only way which would technologically be valid is to use Java PKI and just utilize the private key stored in the OS or some HSM. But this would need the transport to support it. It would work for https, but e.g. not for SOAP WS-Security (regardless if https or http), nor for many other login mechanism. Proposed solution: I like Romains idea with the SPI. What about an interface 'ConfigFilter' which provides 2 different methods, one for 'real' and the other one for 'logged'/'masked' values? This ConfigFilter class could e.g. also used to transparently do the symmetric decryption for configuration which gets stored encrypted. mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[
https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684601#comment-13684601
]
John D. Ament commented on DELTASPIKE-382:
--
What if it were even simpler?
public interface ConfigPrintChecker { //or some other name
public boolean displayKey(String key);
public boolean displayMasked(String key);
}
Then let whoever create an implementation that matches their needs
mask out passwords and other credentials
Key: DELTASPIKE-382
URL: https://issues.apache.org/jira/browse/DELTASPIKE-382
Project: DeltaSpike
Issue Type: New Feature
Components: Configuration
Affects Versions: 0.4
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 0.5
Our configuration mechanism currently logs all the configured values.
This makes it hard to use it for passwords and stuff.
I suggest we introduce some specific prefix property to configure configs
which contain sensitive information.
For the key 'some.random.password' this could look like:
deltaspike_config.mask.some.random.password=true
In the log we would in this case just output the information whether and
where we did find some value, but not print the details for all configs which
start with all of the configured masks.
I'm not yet sure though how to configure this best. Suggestions appreciated!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CDI Query import
Hi Thomas, Great work so far. I just browsed through the doc and add two minor corrections (see my pull request). Will take a look at the code now. Also I have some suggestions for features, but I guess I can add them myself, once we have added this to deltaspike Cheers, Arne Am 14.06.13 11:55 schrieb Thomas Hug unter thomas@gmail.com: Hey all Any suggestions on how to proceed with the CDI Query import? So far we have - a proposal on the API [1] - a cleaned out branch depending on DS core and PartialBeans, running on the JBoss, TomEE and Glassfish profiles [2] - a reasonable amount of documentation [3] So what'd be next, anything still to adapt/missing? [1] https://cwiki.apache.org/DeltaSpike/repository-drafts.html [2] https://github.com/ctpconsulting/query/tree/dsimport [3] https://github.com/ctpconsulting/query/tree/dsimport#readme
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684609#comment-13684609 ] Gerhard Petracek commented on DELTASPIKE-382: - @mark: in config-sources like jndi you don't only have values configured via/for deltaspike. exposing info from jndi is way more common, because it doesn't even have to be the goal to expose sensitive info. like you said - if e.g. an operations guy is interested in all config-values (not just configured via/for ds) and just logs everything, any masking done in ds is useless. - i don't agree because (again): checking logs before exposing them is imo by no way optional esp. if you store passwords as plain text in a common config-source which might be logged for many other reasons. that would be just highly careless, since there might be even other logged confidential info which isn't stored in a config. mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[
https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684626#comment-13684626
]
Mark Struberg commented on DELTASPIKE-382:
--
[~gpetracek]
checking logs before exposing them is imo by no way optional
sorry that's crap. I'm not talking about _externally_ exposing them, but in a
well setup scenario all Developers have access to the logs. This is one of the
main parts all the DevOps movement is about: to care about all those logs
TOGETHER with the operations team. Thus the developers must take care that
sensitive info doesn't end up in the log at all.
I think the ConfigFilter would provide all this and even more functionality
like on the fly decryption.
[~johndament]
Kind of, but instead I'd return the filtered Strings
public interface ConfigFilter {
String filterValue(String key, String value);
String filterValueForLog(String key, String value);
}
plus provide a default impl wich does only return value for the first method
and the logic Romain suggested in the ForLog method.
mask out passwords and other credentials
Key: DELTASPIKE-382
URL: https://issues.apache.org/jira/browse/DELTASPIKE-382
Project: DeltaSpike
Issue Type: New Feature
Components: Configuration
Affects Versions: 0.4
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 0.5
Our configuration mechanism currently logs all the configured values.
This makes it hard to use it for passwords and stuff.
I suggest we introduce some specific prefix property to configure configs
which contain sensitive information.
For the key 'some.random.password' this could look like:
deltaspike_config.mask.some.random.password=true
In the log we would in this case just output the information whether and
where we did find some value, but not print the details for all configs which
start with all of the configured masks.
I'm not yet sure though how to configure this best. Suggestions appreciated!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684635#comment-13684635 ] Romain Manni-Bucau commented on DELTASPIKE-382: --- An alternative would be to fire an event when container is started and log with an observer at this moment, the observer would be overridable so deactivable mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684641#comment-13684641 ] Gerhard Petracek commented on DELTASPIKE-382: - @mark: so far i haven't said something about the spi (that would be a different jira-ticket). i just don't agree with the out-of-the box masking which actively supports a questionable approach. yes - depending on the use-case you might need to decrypt a password at some point, but without code-reviews, security audits,... you have to trust your developers anyway. or ensure security in a better way. there are enough tools like https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin which do that in a general fashion and not only within ds. btw. using strong language doesn't make anything more accurate and i refuse such a style in any discussion here. mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684643#comment-13684643 ] Gerhard Petracek commented on DELTASPIKE-382: - @romain: yes - if we change the default logging, we don't have an issue with that. i haven't said that there is nothing to change. as i said before, i haven't said something about the suggested spi which is a different story (and doesn't fit to the topic of this ticket which is about masking something out-of-the-box). i just don't agree with the need to mask something which would be only masked for accessing it via ds-apis. mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (DELTASPIKE-382) mask out passwords and other credentials
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684641#comment-13684641 ] Gerhard Petracek edited comment on DELTASPIKE-382 at 6/16/13 1:04 PM: -- @mark: so far i haven't said something about the spi (that would be a different jira-ticket). i just don't agree with the out-of-the-box masking which actively supports a questionable approach. yes - depending on the use-case you might need to decrypt a password at some point, but without code-reviews, security audits,... you have to trust your developers anyway. - ensure security in a better way. there are enough tools like https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin which do that in a general fashion and not only within ds. (this one for sure not for prod. - it's just an open example which shows that you have to do it on a different level and not in a single ds-api. i can't ref. closed examples like specific handlers which would be for sure more appropriate.) btw. using strong language doesn't make anything more accurate and i refuse such a style in any discussion here. was (Author: gpetracek): @mark: so far i haven't said something about the spi (that would be a different jira-ticket). i just don't agree with the out-of-the-box masking which actively supports a questionable approach. yes - depending on the use-case you might need to decrypt a password at some point, but without code-reviews, security audits,... you have to trust your developers anyway. - ensure security in a better way. there are enough tools like https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin which do that in a general fashion and not only within ds. btw. using strong language doesn't make anything more accurate and i refuse such a style in any discussion here. mask out passwords and other credentials Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[DISCUSS] beanval module name
Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
even when speaking? Then the point is who should understand the name, the EG or users. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we (= bv-eg) ~always used bv. it's even used in the bv-spec. document. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
we never had an issue with that in codi where we use bv since 2010. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com even when speaking? Then the point is who should understand the name, the EG or users. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we (= bv-eg) ~always used bv. it's even used in the bv-spec. document. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
Re: [DISCUSS] beanval module name
codi is not that used, and not sure bv is explicit enough in all languages. hibernate uses validator, other can use jsr330/jsr349. Since this module can be an in between 330 and 349 maybe using jsr330 is good but IMO has the same drawback as bv. If you don't follow specs and/or dev them you don't know what it is. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we never had an issue with that in codi where we use bv since 2010. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com even when speaking? Then the point is who should understand the name, the EG or users. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 Gerhard Petracek gerhard.petra...@gmail.com we (= bv-eg) ~always used bv. it's even used in the bv-spec. document. regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com whatever the list is IMO, the point was already mentionned: how many times did you use bv to say bean validation? You never say Java Persistence API but always jpa, for bval that's the opposite IMO. I commonly see bval or beanvalidation but not others. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/16 John D. Ament john.d.am...@gmail.com Gerhard, They may use [bv-dev] as a prefix, but the mailing list name is beanvalidation-dev. On Sun, Jun 16, 2013 at 10:11 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, please check e.g. the official eg/dev list [1]. the subject of mails starts with [bv-dev] regards, gerhard [1] http://lists.jboss.org/pipermail/beanvalidation-dev/ 2013/6/16 John D. Ament john.d.am...@gmail.com gerhard/thomas The problem I have with bv is that no one refers to BeanValidation as bv (in fact, Bean Validation is the shortened form of JavaBeans Validation). Doing a quick google search on bv shows me some STDs. Since google is typically stalking me and knows I ask lots of programming questions, it would typically return the programming references first. Doing a google search for bv bean validation shows beanvalidation.org, however there are no references to bv on that site. romain Yes, I think using bval ties us closely to the Apache impl. I think I generally prefer longer names. For example, we chose partial-bean rather than pb. If it were bean-val instead of beanval, would anyone mind that? John On Sun, Jun 16, 2013 at 9:45 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, in codi we used bv1 (like jpa1, jsf12, jsf20,...). if we don't plan to support multiple versions with separated modules, i tend to like just bv (since we use jpa and jsf for the modules of the corresponding specs). regards, gerhard 2013/6/16 Romain Manni-Bucau rmannibu...@gmail.com As a short name bval is fine but maybe too close of apache impl. So id use bean-validation. Being explicit is good when naming things Le 16 juin 2013 15:25, John D. Ament john.d.am...@gmail.com a écrit : Hi all One of the comments in the introduction of a Bean Validation module is that the name I gave it isn't descriptive/useful. I chose the name beanval since it was a shortened version of Bean Validation that could easily be read via maven. To me, it's descriptive of being related to JSR303 support. One of the other names proposed is bv. If anyone has any recommended names, or questions about the given names, could you speak up? John
[jira] [Comment Edited] (DELTASPIKE-382) mask out passwords and other credentials in our Configuration logs
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684702#comment-13684702 ] Gerhard Petracek edited comment on DELTASPIKE-382 at 6/16/13 6:28 PM: -- to summarize it: #1 i don't agree with masking values for the access via a single ds-api (because it needs to be solved on a different level) #2 i agree that we can improve the current default handling #3 i agree that it should be possible to skip logging (and not masking) in some cases/stages/... (without agreeing with the password use-case - i don't agree with the title of this ticket and the initially used use-case - see #1) #4 if someone uses it for use-cases not everybody here agrees with, they are responsible for it (but imo we shouldn't actively support/document it) was (Author: gpetracek): to summarize it: #1 i don't agree with masking values for the access via a single ds-api (because it needs to be solved on a different level) #2 i agree that we can improve the current default handling #3 i agree that it should be possible to avoid logging in some cases/stages/... (without agreeing with the password use-case - i don't agree with the title of this ticket and the initially used use-case - see #1) #4 if someone uses it for use-cases not everybody here agrees with, they are responsible for it (but imo we shouldn't actively support/document it) mask out passwords and other credentials in our Configuration logs -- Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-382) mask out passwords and other credentials in our Configuration logs
[ https://issues.apache.org/jira/browse/DELTASPIKE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684728#comment-13684728 ] Mark Struberg commented on DELTASPIKE-382: -- parsing ALL log output in production is imo not a good idea. This is way too expensive and could seriously blast performance in many situations. For jenkins it doesn't harm anyone, but in a production environment this is a no-go from a performance pov. ad #1: it's not a single DS method, it really affects the whole configuration area. ad #3: don't see it as a pure password issue, the solution with the SPI is much more flexible. As outlined above you could e.g. also use it for a decryption handler. ad #4: yes, I'll hack it and maintain it. mask out passwords and other credentials in our Configuration logs -- Key: DELTASPIKE-382 URL: https://issues.apache.org/jira/browse/DELTASPIKE-382 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 Our configuration mechanism currently logs all the configured values. This makes it hard to use it for passwords and stuff. I suggest we introduce some specific prefix property to configure configs which contain sensitive information. For the key 'some.random.password' this could look like: deltaspike_config.mask.some.random.password=true In the log we would in this case just output the information whether and where we did find some value, but not print the details for all configs which start with all of the configured masks. I'm not yet sure though how to configure this best. Suggestions appreciated! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Bean Validation Module Name
[+1] beanval BTW, I'll leave this open for about 72 hours. John On Sun, Jun 16, 2013 at 8:42 PM, John D. Ament john.d.am...@gmail.comwrote: All Based on the thread thus far, I'd like to call a vote. These are the two names the seem to have the least angst: beanval bean-validation So, to vote please respond with a +1 or a -1. +1 is for beanval but -1 is for bean-validation I'm not including bv due to the US English connotations. I'm not including bval due to the existing apache project plus references to other names I saw in a quick google search. - John
Re: [VOTE] Bean Validation Module Name
+1 LieGrue, strub - Original Message - From: John D. Ament john.d.am...@gmail.com To: dev@deltaspike.apache.org Cc: Sent: Monday, 17 June 2013, 2:42 Subject: Re: [VOTE] Bean Validation Module Name [+1] beanval BTW, I'll leave this open for about 72 hours. John On Sun, Jun 16, 2013 at 8:42 PM, John D. Ament john.d.am...@gmail.comwrote: All Based on the thread thus far, I'd like to call a vote. These are the two names the seem to have the least angst: beanval bean-validation So, to vote please respond with a +1 or a -1. +1 is for beanval but -1 is for bean-validation I'm not including bv due to the US English connotations. I'm not including bval due to the existing apache project plus references to other names I saw in a quick google search. - John
