[whispersystems] Signal Server: Base64 util and if we are java 8 should we buy all the way in

[Alex Newman]

Does it make sense to move the internal implementation of our Base64 to
https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html

We are already using Optional which ties us to java 8 forever. Speaking of
that, now that we have the optional type does it start to make sense
passing optionals? In addition I noticed we use

javax.validation.constraints.NotNull

should we consider also using jsr-308 for new notnulls?

https://jcp.org/en/jsr/detail?id=208

[Alex Newman]

The version of base64 we use is broken in two regards.


- v2.3.7 - Fixed subtle bug when base 64 input stream contained the
value 01111111, which is an invalid base 64 character but should not throw
an ArrayIndexOutOfBoundsException either. Led to discovery of mishandling
(or potential for better handling) of other bad input characters. You
should now get an IOException if you try decoding something that has bad
characters in it.
- v2.3.6 - Fixed bug when breaking lines and the final byte of the
encoded string ended in the last column; the buffer was not properly shrunk
and contained an extra (null) byte that made it into the string.


We should upstream these changes if we wanna use it. Otherwise we can do
what the author suggest and consider just using java 8's base64

Post by Alex Newman
Does it make sense to move the internal implementation of our Base64 to
https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html
We are already using Optional which ties us to java 8 forever. Speaking of
that, now that we have the optional type does it start to make sense
passing optionals? In addition I noticed we use
javax.validation.constraints.NotNull
should we consider also using jsr-308 for new notnulls?
https://jcp.org/en/jsr/detail?id=208

[Alex Newman]

Here's my example of just moving to the built in java.util.Base64. Think
this makes sense?

https://github.com/posix4e/Signal-Server/commit/692cb57593c91cff344b7c683c657b85e8116638

Post by Alex Newman
The version of base64 we use is broken in two regards.
- v2.3.7 - Fixed subtle bug when base 64 input stream contained the
value 01111111, which is an invalid base 64 character but should not throw
an ArrayIndexOutOfBoundsException either. Led to discovery of mishandling
(or potential for better handling) of other bad input characters. You
should now get an IOException if you try decoding something that has bad
characters in it.
- v2.3.6 - Fixed bug when breaking lines and the final byte of the
encoded string ended in the last column; the buffer was not properly shrunk
and contained an extra (null) byte that made it into the string.
We should upstream these changes if we wanna use it. Otherwise we can do
what the author suggest and consider just using java 8's base64

Post by Alex Newman
Does it make sense to move the internal implementation of our Base64 to
https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html
We are already using Optional which ties us to java 8 forever. Speaking
of that, now that we have the optional type does it start to make sense
passing optionals? In addition I noticed we use
javax.validation.constraints.NotNull
should we consider also using jsr-308 for new notnulls?
https://jcp.org/en/jsr/detail?id=208