[jira] [Created] (BCEL-303) AssertionViolatedException in Pass 3A Verification of invoke instructions

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-303:
-

 Summary: AssertionViolatedException in Pass 3A Verification of 
invoke instructions
 Key: BCEL-303
 URL: https://issues.apache.org/jira/browse/BCEL-303
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: A.class

The verifier throws an assertion violation / INTERNAL ERROR in pass 3A when 
verifying a malformed class file.

As I understand it, the issue is that if class A implements interface B, then 
class A can be pass stage 1 verification even if class B is not resolved. 
However, pass 3A verification of code that invokes a method defined on class A 
assumes that the receiver type and all its interfaces are fully resolved.
h1. Steps to reproduce:

 

Save the attached file as "example/A.class" and run:

java -cp  org.apache.bcel.verifier.Verifier example.A

 

The file A.class was generated automatically by the fuzzer JQF 
(https://github.com/rohanpadhye/jqf).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: example.A

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Pass 2:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" 
org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: 
Missing class: java.lang.ClassNotFoundException: Exception while looking for 
class example.I0: java.io.IOException: Couldn't find: example/I0.class

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitINVOKEVIRTUAL(Pass3aVerifier.java:1315)

 at org.apache.bcel.generic.INVOKEVIRTUAL.accept(INVOKEVIRTUAL.java:89)

 at org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)

Caused by: java.lang.ClassNotFoundException: Exception while looking for class 
example.I0: java.io.IOException: Couldn't find: example/I0.class

 at 
org.apache.bcel.util.MemorySensitiveClassPathRepository.loadClass(MemorySensitiveClassPathRepository.java:97)

 at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:847)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.getMethodRecursive(Pass3aVerifier.java:1181)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitINVOKEVIRTUAL(Pass3aVerifier.java:1304)

 ... 7 more

Caused by: java.io.IOException: Couldn't find: example/I0.class

 at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)

 at org.apache.bcel.util.ClassPath.getInputStream(ClassPath.java:209)

 at org.apache.bcel.util.ClassPath.getInputStream(ClassPath.java:188)

 at 
org.apache.bcel.util.MemorySensitiveClassPathRepository.loadClass(MemorySensitiveClassPathRepository.java:95)

 ... 10 more

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEOMETRY-3) Make Points and Vectors VALJOs

[Matt Juntunen (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523087#comment-16523087
 ] 

Matt Juntunen commented on GEOMETRY-3:
--

I'm getting emails now! Yay!

I think we might have a miscommunication on the current parsing functionality 
in the pull request. All of the 8 (soon to be 10) VALJOs only accept the string 
format returned by the corresponding toString() method. This meets the simple 
one-to-string Object <-> String mapping requirement you mentioned. The formats 
are:
 * Point1D: "(1.0)"
 * Vector1D: "\{1.0}"
 * Point2D: "(1.0, 2.0)"
 * Vector2D: "\{1.0, 2.0}"
 * Point3D: "(1.0, 2.0, 3.0)"
 * Vector3D: "\{1.0, 2.0, 3.0}"
 * S1Point: "(1.0)"
 * S2Point: "(1.0, 2.0)"
 * PolarCoordinates (not in this pull request): "(r=1.0, az=2.0)"
 * SphericalCoordinates (not in this pull request): "(r=1.0, az=2.0, pl=3.0)"

So, the Vector3D.parse() method only accepts strings with the format "\{1,2,3}" 
where there is a set of braces enclosing three comma-delimited floating-point 
numbers. The string "(1,2,3)" will not work since it is enclosed with 
parentheses and not braces. (I'm following the convention of using parenthese 
for points and braces for vectors.)  Similarly, PolarCoordinates.parse() only 
accepts the format "(r=1, az=2)" where there is a set of of parentheses 
enclosing two floating-point numbers where the string "r=" precedes the first 
number and the string "az=" precedes the second. The string "(az=2, r=1)" does 
not work. I chose to put the string prefixes in the PolarCoordinates and 
SphericalCoordinates formats to 1) make it explicit what each number means and 
2) differentiate them from the Point?D formats.

The formats for all of the different VALJO types are very similar and differ 
only in the prefixes and suffixes used, the number of coordinate values, and a 
few special string tokens (ex: "r=" and "az=" in PolarCoordinates). Rather than 
duplicating the low-level string parsing code in each type, I pulled it out 
into the o.a.c.g.core.util.AbstractCoordinateParser and 
o.a.c.g.core.util.SimpleCoordinateFormat classes.

>From previous comments, it seems to me that the only decision that still needs 
>to be made here is where to put the two low-level parser classes. I put them 
>in core because they're used in commons-geometry-euclidean and 
>commons-geometry-spherical, but I have no problem putting them somewhere else 
>if needed. What do you think?

> Make Points and Vectors VALJOs
> --
>
> Key: GEOMETRY-3
> URL: https://issues.apache.org/jira/browse/GEOMETRY-3
> Project: Apache Commons Geometry
>  Issue Type: Improvement
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Minor
>
> Ensure that all Point and Vector classes meet the requirements for being 
> VALJOs as described here: 
> [http://blog.joda.org/2014/03/valjos-value-java-objects.html]. Some of this 
> work has already been done as part of  GEOMETRY-2. The classes to update are:
>  * o.a.c.geometry.euclidean.oned.Point1D/Vector1D
>  * o.a.c.geometry.euclidean.twod.Point2D/Vector2D
>  * o.a.c.geometry.euclidean.threed.Point3D/Vector3D
>  * o.a.c.geometry.spherical.oned.S1Point
>  * o.a.c.geometry.spherical.twod.S2Point
> Required changes include the following:
>  * Create static factory methods for creating instances using the "of" naming 
> convention.
>  * Make constructors private
>  * Add parse methods to return instances from "canonical" toString 
> representation
>  * Update all uses of the class to use the factory methods instead of the 
> constructor
>  
> Pull request: https://github.com/apache/commons-geometry/pull/4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1400) StringUtils: Add method for masking strings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522744#comment-16522744
 ] 

ASF GitHub Bot commented on LANG-1400:
--

Github user stokito commented on the issue:

https://github.com/apache/commons-lang/pull/335
  
Hi @greenman18523 
> would you consider an extra parameter, to clearly specify the minimum 
number of masked characters?
For those use cases which I mentioned (masking credit cards and passwords) 
this looks not needed for me. Maybe you know some cases when this may be needed?

As I understood you are telling about more safety and do not unmask any 
symbol if incoming string is too short while implementation which I proposed 
will try to show at least some symbols from start.
For example `mask("123456", 4, 4) = "12"` which makes hidden symbols 
more guessable.
But, to be honest, if someone uses so short password then it doesn't matter 
if it will be shown.

Another solution in this case we can mask everything when str len is 6 < 
unmaskendStart 4 + unmaskedEnd 4. I.e.  `mask("123456", 4, 4) = "**"`. This 
is easier to understood but in the same time it still may be useful to unmask 
at least something but I don't think it's so critical.
What do you think about this proposition? E.g. 
```
mask("12345678", 4, 4) = ""
mask("123456789", 4, 4) = "5"
mask("1234567890", 4, 4) = "56"
```

I hope that `unmaskedStart` and `unmaskedEnd` in real life will be always 
reasonable (1-6) and the incoming string will be always bigger. We can actually 
restrict passing strings less that some length  and throw an exception. 
But from possible use cases it looks that `mask()` function should be 
failsafe because it may be used just for logging of external input which can be 
anything and we shouldn't break it's processing. I even think about returning 
an empty string if null was passed.

Also we have to think about performance because I expect that the function 
will be widely used for in logging filters for any incoming request.


> StringUtils: Add method for masking strings
> ---
>
> Key: LANG-1400
> URL: https://issues.apache.org/jira/browse/LANG-1400
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> It would be great to have a function which allows to mask the original str by 
> replacing it's
> characters with the specified character-mask. For eaxmple to mask credit card:
> {code}
> mask("3566002020360505", 4, 4, '*') = "35660505"
> {code}
> Thus the number was hidden by asterisks while first and last four digits are 
> unmasked and seen.
> Common use case is to hide sensitive information from logs, by using it in 
> toString() of classes or in inputs to log calls.
> I think this is "must have" functionality for Commons Lang library because 
> from my experience in almost all bit projects what I saw was their home grown 
> masking function.
> I think this is very important also because this is required for masking 
> credit card numbers by PCI compliance. Also new GDPR rules requires to hide 
> personal info as much as possible so masking of First and Last names now is 
> required by laws.
> To make the world safer place the utility for masking should be already 
> existing in platform to avoid situations when developer think  "this is 
> better to mask but I don't have enough time now so let's do this latter" 
> until leak happens.
> IMHO this should be implemented even in `String` class itself.
> From my experience what I saw was usually few masking usages and styles:
> 1. masking of passwords and names: only first and last symbols are shown, 
> mask char is `*`
> 2. masking of credit cards: only first and last 4 or 6 symbols are shown, 
> mask char is `*`.
> 3. credit card number shortest masking of last symbols i.e. 
> `mask("4242424242424242") == " *4242"` but it's not so often used, I just 
> wanted to mention.
> 4. not masking but showing a length just so see that value was passed. This 
> can be easily achieved by usual `String.legth()` method.
> There is already some pull request 
> [https://github.com/apache/commons-lang/pull/332] but I decided to create the 
> ticket because we also need to support masking for ToStringBuilder and I 
> would like to propose [PR with my own implementation of mask() 
> function|https://github.com/apache/commons-lang/pull/335].
> If you accept my PR then I'll send another one with a new annotation 
> @ToStringMasked in accordance to 
> [@ToStringExclude|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/ToStringExclude.html]
>  which will mark that fields should be masked. Possible usage I see like:
> 

[GitHub] commons-lang issue #335: LANG-1400: Add StringUtils.mask() function

[stokito]

Github user stokito commented on the issue:

https://github.com/apache/commons-lang/pull/335
  
Hi @greenman18523 
> would you consider an extra parameter, to clearly specify the minimum 
number of masked characters?
For those use cases which I mentioned (masking credit cards and passwords) 
this looks not needed for me. Maybe you know some cases when this may be needed?

As I understood you are telling about more safety and do not unmask any 
symbol if incoming string is too short while implementation which I proposed 
will try to show at least some symbols from start.
For example `mask("123456", 4, 4) = "12"` which makes hidden symbols 
more guessable.
But, to be honest, if someone uses so short password then it doesn't matter 
if it will be shown.

Another solution in this case we can mask everything when str len is 6 < 
unmaskendStart 4 + unmaskedEnd 4. I.e.  `mask("123456", 4, 4) = "**"`. This 
is easier to understood but in the same time it still may be useful to unmask 
at least something but I don't think it's so critical.
What do you think about this proposition? E.g. 
```
mask("12345678", 4, 4) = ""
mask("123456789", 4, 4) = "5"
mask("1234567890", 4, 4) = "56"
```

I hope that `unmaskedStart` and `unmaskedEnd` in real life will be always 
reasonable (1-6) and the incoming string will be always bigger. We can actually 
restrict passing strings less that some length  and throw an exception. 
But from possible use cases it looks that `mask()` function should be 
failsafe because it may be used just for logging of external input which can be 
anything and we shouldn't break it's processing. I even think about returning 
an empty string if null was passed.

Also we have to think about performance because I expect that the function 
will be widely used for in logging filters for any incoming request.


---

[jira] [Commented] (GEOMETRY-3) Make Points and Vectors VALJOs

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEOMETRY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522129#comment-16522129
 ] 

Gilles commented on GEOMETRY-3:
---

I've filed a report in order to get the notifications: INFRA-16679.
{quote}parse strings with the format "(r=1, az=2)"
{quote}
The flexibility goes beyond the ValJO requirement (simple one-to-one conversion 
{{Object}} <-> {{String}}). For example, allowing the above representation, 
there would be no argument to not also allow "(az=2, r=1)" and so on.
 We should be careful not to mix the ValJO's {{String}} representation with 
data interchange considerations (where flexible input/output has its place of 
course).
 Here, IMHO, flexibility should be reduced to its minimum, and handled by the 
calls to {{Double.parseDouble}} method; the rest of the format should be fixed, 
and thus the name of the parameters "r" and "az" are redundant.
 What must be implemented is similar to the code in {{Complex}}: an opening 
"(", several numbers separated by a "," and a closing ")".

Code that converts geometrical objects built by this library to useful data 
formats should be defined in a different module so that those implementations 
can evolve independently. Moreover, data interchange codes could depend on 
external libraries e.g. to produce platform-independent binary representations.

> Make Points and Vectors VALJOs
> --
>
> Key: GEOMETRY-3
> URL: https://issues.apache.org/jira/browse/GEOMETRY-3
> Project: Apache Commons Geometry
>  Issue Type: Improvement
>Reporter: Matt Juntunen
>Assignee: Matt Juntunen
>Priority: Minor
>
> Ensure that all Point and Vector classes meet the requirements for being 
> VALJOs as described here: 
> [http://blog.joda.org/2014/03/valjos-value-java-objects.html]. Some of this 
> work has already been done as part of  GEOMETRY-2. The classes to update are:
>  * o.a.c.geometry.euclidean.oned.Point1D/Vector1D
>  * o.a.c.geometry.euclidean.twod.Point2D/Vector2D
>  * o.a.c.geometry.euclidean.threed.Point3D/Vector3D
>  * o.a.c.geometry.spherical.oned.S1Point
>  * o.a.c.geometry.spherical.twod.S2Point
> Required changes include the following:
>  * Create static factory methods for creating instances using the "of" naming 
> convention.
>  * Make constructors private
>  * Add parse methods to return instances from "canonical" toString 
> representation
>  * Update all uses of the class to use the factory methods instead of the 
> constructor
>  
> Pull request: https://github.com/apache/commons-geometry/pull/4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #334: Code refactoring and cleaning

[ingvarc]

Github user ingvarc commented on the issue:

https://github.com/apache/commons-lang/pull/334
  
@stokito Thanks for pointing that out, I'll keep it in mind in future.
@kinow I like the idea of a validation block and the normal behaviour. It 
seems to me that in this case it is more readable and clear. I'll rebase 
commits and make force push asap.
@kinow, @PascalSchumacher, @aaabramov ans @stokito Since it's one of my 
first open-source contributions I really appreciate your observations and 
comments. 


---