[jira] [Closed] (CODEC-288) during Base64 decode for 24 byte length string ,the function returns byte array which is less than 18 bytes
[
https://issues.apache.org/jira/browse/CODEC-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed CODEC-288.
--
Resolution: Cannot Reproduce
> during Base64 decode for 24 byte length string ,the function returns byte
> array which is less than 18 bytes
> ---
>
> Key: CODEC-288
> URL: https://issues.apache.org/jira/browse/CODEC-288
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.5
> Environment: effected all the stacks
>Reporter: sagarika
>Priority: Major
>
> string of byte length 24 AQFxB7VyAgEPEMdg
> returned byte array length :6 ideally it should be of length 18.
>
> public byte[] decode(String pArray) {
> return this.decode(StringUtils.getBytesUtf8(pArray));
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CODEC-182) Allow real salts in Sha2Crypt
[ https://issues.apache.org/jira/browse/CODEC-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869881#comment-17869881 ] Sebb commented on CODEC-182: It does seem odd to insist on providing a prefix (albeit not yet validated) when invoking a method that specifies the algorithm version in its name. Would it make sense to allow the prefix to be omitted? Then what about the rounds= qualifier? That would still need to be provided as part of the salt. I'm not sure it is possible to allow for a 'real salt' except by extending the API. > Allow real salts in Sha2Crypt > - > > Key: CODEC-182 > URL: https://issues.apache.org/jira/browse/CODEC-182 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Felix Kaser >Priority: Minor > > The javadoc for all the methods in Sha2Crypt clearly states to pass a "real > salt" in as parameter, without prefix and without "rounds=...". But the crypt > method first of all checks if the salt matches a regex pattern, which > requires it to contain at least a leading $5$ or $6$, possibly a rounds=... > and then the real salt. > Imho either the javadoc should be adapted to tell developers which salt to > pass in, or the crypt method should match the salt after adding the prefix > itself. > I am new to the apache commons community, so please correct me if I'm totally > wrong here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CODEC-182) Allow real salts in Sha2Crypt
[ https://issues.apache.org/jira/browse/CODEC-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869743#comment-17869743 ] Sebb commented on CODEC-182: See https://github.com/apache/commons-codec/pull/301 > Allow real salts in Sha2Crypt > - > > Key: CODEC-182 > URL: https://issues.apache.org/jira/browse/CODEC-182 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Felix Kaser >Priority: Minor > > The javadoc for all the methods in Sha2Crypt clearly states to pass a "real > salt" in as parameter, without prefix and without "rounds=...". But the crypt > method first of all checks if the salt matches a regex pattern, which > requires it to contain at least a leading $5$ or $6$, possibly a rounds=... > and then the real salt. > Imho either the javadoc should be adapted to tell developers which salt to > pass in, or the crypt method should match the salt after adding the prefix > itself. > I am new to the apache commons community, so please correct me if I'm totally > wrong here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CODEC-182) Allow real salts in Sha2Crypt
[ https://issues.apache.org/jira/browse/CODEC-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869700#comment-17869700 ] Sebb commented on CODEC-182: Crypt.crypt() delegates to Sha2Crypt, but it should at least ensure that the correct Sha2Crypt method is chosen for the prefix. The Sha2Crypt implementation currently requires the salt to include a valid prefix, but does not check it for consistency with the method. It might make sense to add such a check, and update the Javadoc to state the actual requirements for the salt. > Allow real salts in Sha2Crypt > - > > Key: CODEC-182 > URL: https://issues.apache.org/jira/browse/CODEC-182 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Felix Kaser >Priority: Minor > > The javadoc for all the methods in Sha2Crypt clearly states to pass a "real > salt" in as parameter, without prefix and without "rounds=...". But the crypt > method first of all checks if the salt matches a regex pattern, which > requires it to contain at least a leading $5$ or $6$, possibly a rounds=... > and then the real salt. > Imho either the javadoc should be adapted to tell developers which salt to > pass in, or the crypt method should match the salt after adding the prefix > itself. > I am new to the apache commons community, so please correct me if I'm totally > wrong here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COMPRESS-684) Why use assert rather than throwing an Exception
[ https://issues.apache.org/jira/browse/COMPRESS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-684. --- Resolution: Fixed Fixed in https://github.com/apache/commons-compress/commit/01e80d89baf153342c23405151f76623721e > Why use assert rather than throwing an Exception > > > Key: COMPRESS-684 > URL: https://issues.apache.org/jira/browse/COMPRESS-684 > Project: Commons Compress > Issue Type: Bug > Reporter: Sebb >Priority: Major > > The code here uses assert: > [https://github.com/apache/commons-compress/blob/b6c6b1e71087ae3e31d1024069084512a243eed7/src/main/java/org/apache/commons/compress/compressors/gzip/GzipCompressorInputStream.java#L207] > This seems odd for user code, as the assert may be disabled. > It would be more usual to throw an Exception instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IO-858) FileUtilsWaitForTest does not test anything useful
[ https://issues.apache.org/jira/browse/IO-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-858. - Resolution: Fixed Fixed by aa43f4f9f31a49d06a6860d6b6569ec751a6d707 and ab165f7b7f24074faccb2e54feba617e9fc21f15 > FileUtilsWaitForTest does not test anything useful > -- > > Key: IO-858 > URL: https://issues.apache.org/jira/browse/IO-858 > Project: Commons IO > Issue Type: Bug > Reporter: Sebb >Priority: Major > > AFAICT, FileUtilsWaitForTest [1] does not do anything useful currently. > > Of the 3 tests, 2 don't check the return status, nor do they appear to be > trying to test for Exceptions. > The 3rd test - testWaitForInterrupted - appears to be testing the response of > FileUtils.waitFor() to an interruption. However it does not do so, as the > waitFor() target is FileUtils.current() which is certain to exist. As it > stands, AFAICT the test checks if the main thread can interrupt the test > thread before it sets the wasInterrupted flag. This currently relies on > relative thread timings, so it is not surprising that the test is flaky. > There should ideally be a test for IO-488, as well as tests for targets that > are present or missing or which appear during a wait. > > [1] > https://github.com/apache/commons-io/blob/master/src/test/java/org/apache/commons/io/FileUtilsWaitForTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-858) FileUtilsWaitForTest does not test anything useful
Sebb created IO-858: --- Summary: FileUtilsWaitForTest does not test anything useful Key: IO-858 URL: https://issues.apache.org/jira/browse/IO-858 Project: Commons IO Issue Type: Bug Reporter: Sebb AFAICT, FileUtilsWaitForTest [1] does not do anything useful currently. Of the 3 tests, 2 don't check the return status, nor do they appear to be trying to test for Exceptions. The 3rd test - testWaitForInterrupted - appears to be testing the response of FileUtils.waitFor() to an interruption. However it does not do so, as the waitFor() target is FileUtils.current() which is certain to exist. As it stands, AFAICT the test checks if the main thread can interrupt the test thread before it sets the wasInterrupted flag. This currently relies on relative thread timings, so it is not surprising that the test is flaky. There should ideally be a test for IO-488, as well as tests for targets that are present or missing or which appear during a wait. [1] https://github.com/apache/commons-io/blob/master/src/test/java/org/apache/commons/io/FileUtilsWaitForTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-684) Why use assert rather than throwing an Exception
[ https://issues.apache.org/jira/browse/COMPRESS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868815#comment-17868815 ] Sebb commented on COMPRESS-684: --- See also GHA build at: https://github.com/apache/commons-compress/actions/runs/10102486795 > Why use assert rather than throwing an Exception > > > Key: COMPRESS-684 > URL: https://issues.apache.org/jira/browse/COMPRESS-684 > Project: Commons Compress > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The code here uses assert: > [https://github.com/apache/commons-compress/blob/b6c6b1e71087ae3e31d1024069084512a243eed7/src/main/java/org/apache/commons/compress/compressors/gzip/GzipCompressorInputStream.java#L207] > This seems odd for user code, as the assert may be disabled. > It would be more usual to throw an Exception instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-684) Why use assert rather than throwing an Exception
[ https://issues.apache.org/jira/browse/COMPRESS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868813#comment-17868813 ] Sebb commented on COMPRESS-684: --- Just tried that, and the tests all passed. > Why use assert rather than throwing an Exception > > > Key: COMPRESS-684 > URL: https://issues.apache.org/jira/browse/COMPRESS-684 > Project: Commons Compress > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The code here uses assert: > [https://github.com/apache/commons-compress/blob/b6c6b1e71087ae3e31d1024069084512a243eed7/src/main/java/org/apache/commons/compress/compressors/gzip/GzipCompressorInputStream.java#L207] > This seems odd for user code, as the assert may be disabled. > It would be more usual to throw an Exception instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COMPRESS-684) Why use assert rather than throwing an Exception
Sebb created COMPRESS-684: - Summary: Why use assert rather than throwing an Exception Key: COMPRESS-684 URL: https://issues.apache.org/jira/browse/COMPRESS-684 Project: Commons Compress Issue Type: Bug Reporter: Sebb The code here uses assert: [https://github.com/apache/commons-compress/blob/b6c6b1e71087ae3e31d1024069084512a243eed7/src/main/java/org/apache/commons/compress/compressors/gzip/GzipCompressorInputStream.java#L207] This seems odd for user code, as the assert may be disabled. It would be more usual to throw an Exception instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NET-710) Timestamp parsing fails around the change to daylight savings
[
https://issues.apache.org/jira/browse/NET-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-710.
--
Resolution: Not A Problem
OK, glad your issue has been solved.
If there is some Javadoc or other documentation that could be improved to make
the API clearer, feel free to raise a PR with suggested changes.
> Timestamp parsing fails around the change to daylight savings
> -
>
> Key: NET-710
> URL: https://issues.apache.org/jira/browse/NET-710
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3, 3.8.0
>Reporter: Mike Baranczak
>Priority: Major
>
> {{String ts = "Mar 13 02:33";}}
> {{Calendar serverTime = Calendar.getInstance(TimeZone.getTimeZone("EDT"),
> Locale.US);}}
> {{serverTime.set(2022, 2, 16, 14, 0);}}
> {{Calendar c = new FTPTimestampParserImpl().parseTimestamp(ts, serverTime);}}
>
> {{Result:}}
>
> {{java.text.ParseException: Timestamp 'Mar 13 02:33' could not be parsed
> using a server time of Wed Mar 16 10:00:54 EDT 2022}}
> {{ at
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp
> (FTPTimestampParserImpl.java:246)}}
>
> I can't tell what's going on, but this seems to have something to do with the
> transition to Daylight Savings Time, which happened on Sunday, March 13. I
> ran into this bug when trying to get a list of recent files from an FTP
> server. (UnixFTPEntryParser ignores the exception silently, which isn't a
> great idea, either.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NET-710) Timestamp parsing fails around the change to daylight savings
[
https://issues.apache.org/jira/browse/NET-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844357#comment-17844357
]
Sebb commented on NET-710:
--
Remember that the listing is generated in the timezone of the server, so
timestamps only have to make sense in that context.
I'm inclined to close the issue as invalid, unless it can be shown that parsing
fails when the appropriate server time parameter is provided.
BTW, modern FTP servers are likely to support MLSD/MLST which do not suffer
from parsing issues; they should be used rather than LIST where possible.
> Timestamp parsing fails around the change to daylight savings
> -
>
> Key: NET-710
> URL: https://issues.apache.org/jira/browse/NET-710
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3, 3.8.0
>Reporter: Mike Baranczak
>Priority: Major
>
> {{String ts = "Mar 13 02:33";}}
> {{Calendar serverTime = Calendar.getInstance(TimeZone.getTimeZone("EDT"),
> Locale.US);}}
> {{serverTime.set(2022, 2, 16, 14, 0);}}
> {{Calendar c = new FTPTimestampParserImpl().parseTimestamp(ts, serverTime);}}
>
> {{Result:}}
>
> {{java.text.ParseException: Timestamp 'Mar 13 02:33' could not be parsed
> using a server time of Wed Mar 16 10:00:54 EDT 2022}}
> {{ at
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp
> (FTPTimestampParserImpl.java:246)}}
>
> I can't tell what's going on, but this seems to have something to do with the
> transition to Daylight Savings Time, which happened on Sunday, March 13. I
> ran into this bug when trying to get a list of recent files from an FTP
> server. (UnixFTPEntryParser ignores the exception silently, which isn't a
> great idea, either.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NET-710) Timestamp parsing fails around the change to daylight savings
[
https://issues.apache.org/jira/browse/NET-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844338#comment-17844338
]
Sebb commented on NET-710:
--
I still cannot reproduce the issue.
What TZ are you running the test under?
Note that the serverTime parameter is supposed to represent the server time, so
should use the server TZ and timestamp.
> Timestamp parsing fails around the change to daylight savings
> -
>
> Key: NET-710
> URL: https://issues.apache.org/jira/browse/NET-710
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3, 3.8.0
>Reporter: Mike Baranczak
>Priority: Major
>
> {{String ts = "Mar 13 02:33";}}
> {{Calendar serverTime = Calendar.getInstance(TimeZone.getTimeZone("EDT"),
> Locale.US);}}
> {{serverTime.set(2022, 2, 16, 14, 0);}}
> {{Calendar c = new FTPTimestampParserImpl().parseTimestamp(ts, serverTime);}}
>
> {{Result:}}
>
> {{java.text.ParseException: Timestamp 'Mar 13 02:33' could not be parsed
> using a server time of Wed Mar 16 10:00:54 EDT 2022}}
> {{ at
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp
> (FTPTimestampParserImpl.java:246)}}
>
> I can't tell what's going on, but this seems to have something to do with the
> transition to Daylight Savings Time, which happened on Sunday, March 13. I
> ran into this bug when trying to get a list of recent files from an FTP
> server. (UnixFTPEntryParser ignores the exception silently, which isn't a
> great idea, either.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NET-710) Timestamp parsing fails around the change to daylight savings
[
https://issues.apache.org/jira/browse/NET-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844233#comment-17844233
]
Sebb commented on NET-710:
--
I've added a separate branch which tests against the release jars from 3.7
through to 3.10.0 using windows, ubuntu and macOS.
All succeed.
https://github.com/apache/commons-net/actions/runs/8983633260
We cannot fix something that does not break for us.
> Timestamp parsing fails around the change to daylight savings
> -
>
> Key: NET-710
> URL: https://issues.apache.org/jira/browse/NET-710
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3, 3.8.0
>Reporter: Mike Baranczak
>Priority: Major
>
> {{String ts = "Mar 13 02:33";}}
> {{Calendar serverTime = Calendar.getInstance(TimeZone.getTimeZone("EDT"),
> Locale.US);}}
> {{serverTime.set(2022, 2, 16, 14, 0);}}
> {{Calendar c = new FTPTimestampParserImpl().parseTimestamp(ts, serverTime);}}
>
> {{Result:}}
>
> {{java.text.ParseException: Timestamp 'Mar 13 02:33' could not be parsed
> using a server time of Wed Mar 16 10:00:54 EDT 2022}}
> {{ at
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp
> (FTPTimestampParserImpl.java:246)}}
>
> I can't tell what's going on, but this seems to have something to do with the
> transition to Daylight Savings Time, which happened on Sunday, March 13. I
> ran into this bug when trying to get a list of recent files from an FTP
> server. (UnixFTPEntryParser ignores the exception silently, which isn't a
> great idea, either.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NET-710) Timestamp parsing fails around the change to daylight savings
[
https://issues.apache.org/jira/browse/NET-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844070#comment-17844070
]
Sebb commented on NET-710:
--
Cannot reproduce the error on 3.10.0 or 3.9.0 using Java8 and Ubuntu.
See the GHA log here
https://github.com/apache/commons-net/actions/runs/8977664771
We will need more details on OS and Java versions
> Timestamp parsing fails around the change to daylight savings
> -
>
> Key: NET-710
> URL: https://issues.apache.org/jira/browse/NET-710
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3, 3.8.0
>Reporter: Mike Baranczak
>Priority: Major
>
> {{String ts = "Mar 13 02:33";}}
> {{Calendar serverTime = Calendar.getInstance(TimeZone.getTimeZone("EDT"),
> Locale.US);}}
> {{serverTime.set(2022, 2, 16, 14, 0);}}
> {{Calendar c = new FTPTimestampParserImpl().parseTimestamp(ts, serverTime);}}
>
> {{Result:}}
>
> {{java.text.ParseException: Timestamp 'Mar 13 02:33' could not be parsed
> using a server time of Wed Mar 16 10:00:54 EDT 2022}}
> {{ at
> org.apache.commons.net.ftp.parser.FTPTimestampParserImpl.parseTimestamp
> (FTPTimestampParserImpl.java:246)}}
>
> I can't tell what's going on, but this seems to have something to do with the
> transition to Daylight Savings Time, which happened on Sunday, March 13. I
> ran into this bug when trying to get a list of recent files from an FTP
> server. (UnixFTPEntryParser ignores the exception silently, which isn't a
> great idea, either.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-851) FileSystemUtils no longer throws IllegalStateException
[ https://issues.apache.org/jira/browse/IO-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832224#comment-17832224 ] Sebb commented on IO-851: - That's IllegalArgumentException, not IllegalStateException. I just did a search for IllegalStateException and it only appears in Javadoc. > FileSystemUtils no longer throws IllegalStateException > -- > > Key: IO-851 > URL: https://issues.apache.org/jira/browse/IO-851 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb >Priority: Minor > > The recent change to use NIO means that the code no longer throws > IllegalStateException, contrary to the Javadoc: > https://github.com/apache/commons-io/commit/59129bcf283ffa5a46d0872e173a4e037575c581 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IO-851) FileSystemUtils no longer throws IllegalStateException
Sebb created IO-851: --- Summary: FileSystemUtils no longer throws IllegalStateException Key: IO-851 URL: https://issues.apache.org/jira/browse/IO-851 Project: Commons IO Issue Type: Bug Reporter: Sebb The recent change to use NIO means that the code no longer throws IllegalStateException, contrary to the Javadoc: https://github.com/apache/commons-io/commit/59129bcf283ffa5a46d0872e173a4e037575c581 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-651) Decompress BZIP2 File Max Output is 900000 chars
[
https://issues.apache.org/jira/browse/COMPRESS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824955#comment-17824955
]
Sebb commented on COMPRESS-651:
---
I tried halving BZip2Constants.BASEBLOCKSIZE to 50_000, and the output file
size is 450_000; it looks like the output size is being limited to the block
size.
> Decompress BZIP2 File Max Output is 90 chars
>
>
> Key: COMPRESS-651
> URL: https://issues.apache.org/jira/browse/COMPRESS-651
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.24.0
> Environment: Plain Java in IntelliJ
>Reporter: Ahmadin Badruddin
>Priority: Major
> Attachments: my10m.tar.bz2
>
>
> I tried to uncompress a big file (a few MBs) of bz2 file using
> BZip2CompressorInputStream, the max output I can get is 90 in size.
> The following example
> {code:java}
> -rw-r--r-- 1 ahmadin staff 167283773 Nov 9 15:50 test.tar.bz2
> -rw-r--r-- 1 ahmadin staff 90 Nov 9 15:51 test.tar {code}
> The code I use is the example from
> [https://commons.apache.org/proper/commons-compress/examples.html]
> {code:java}
> public class BZ2Extract {
> public static void main(String[] args) {
> int buffersize = 102400;
> InputStream fin = null;
> try {
> fin = Files.newInputStream(Paths.get("/cfm/test.tar.bz2"));
> BufferedInputStream in = new BufferedInputStream(fin);
> OutputStream out =
> Files.newOutputStream(Paths.get("/cfm/test.tar"));
> BZip2CompressorInputStream bzIn = new
> BZip2CompressorInputStream(in);
> final byte[] buffer = new byte[buffersize];
> int n = 0;
> while (-1 != (n = bzIn.read(buffer))) {
> out.write(buffer, 0, n);
> }
> out.close();
> bzIn.close();
> } catch (IOException e) {
> throw new RuntimeException(e);
> }
> }
> } {code}
> If I use bzip2 on my mac to uncompress, the file size is 1199749120 after
> uncompressing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IO-413) deleteQuietly(File) should try to closeOnDelete too
[
https://issues.apache.org/jira/browse/IO-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved IO-413.
-
Resolution: Won't Do
Agreed
> deleteQuietly(File) should try to closeOnDelete too
> ---
>
> Key: IO-413
> URL: https://issues.apache.org/jira/browse/IO-413
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Reporter: David Mollitor
>Priority: Minor
>
> Something like...
> {code}
> public static boolean deleteQuietly(final File file, final boolean
> deleteOnExit) {
> boolean fileDeleted = false;
> if (file == null) {
> return false;
> }
> try {
> if (file.isDirectory()) {
> cleanDirectory(file);
> }
> } catch (final Exception ignored) {
> }
> try {
> fileDeleted = file.delete();
> } catch (final Exception ignored) {
> return false;
> }
>if (deleteOnExit && !fileDeleted)
>{
>file.deleteOnExit();
>}
> return fileDeleted;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (LANG-1713) ArrayUtils will return null when adding two null arrays, but undocumented
[
https://issues.apache.org/jira/browse/LANG-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb reopened LANG-1713:
> ArrayUtils will return null when adding two null arrays, but undocumented
> -
>
> Key: LANG-1713
> URL: https://issues.apache.org/jira/browse/LANG-1713
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.13.0
>Reporter: John Hendrikx
>Priority: Minor
> Labels: Null-Safety, null
> Fix For: 3.15.0
>
>
>
> {color:#00}The code below makes use of `clone`; however `clone` will
> return `null` when the array is null.{color}
>
> {color:#00}This means that doing ArrayUtils.addAll(null, null) can return
> null. The documentation however makes it appear that this can never happen
> ("it is always a new array", and "@return The new boolean[] array."){color}
>
>
> {color:#3f5fbf}/**{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}Adds all the
> elements of the given arrays into a new array.{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}The new
> array contains all of the element of \{@code array1} followed{color}
> {color:#3f5fbf} * by all of the elements \{@code array2}. When an array is
> returned, it is always{color}
> {color:#3f5fbf} * a new array.{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} * ArrayUtils.addAll(array1, null) = cloned copy of
> array1{color}
> {color:#3f5fbf} * ArrayUtils.addAll(null, array2) = cloned copy of
> array2{color}
> {color:#3f5fbf} * ArrayUtils.addAll([], []) = []{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array1
> the first array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array2
> the second array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@return{color}{color:#3f5fbf} The new
> boolean[] array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@since{color}{color:#3f5fbf}
> 2.1{color}
> {color:#3f5fbf} */{color}
> {color:#80}public{color}{color:#00}
> {color}{color:#80}static{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[]
> {color}{color:#00}addAll{color}{color:#00}({color}{color:#80}final{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[]
> {color}{color:#6a3e3e}array1{color}{color:#00},
> {color}{color:#80}final{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}...
> {color}{color:#6a3e3e}array2{color}{color:#00}) {{color}
> {color:#80}if{color}{color:#00}
> ({color}{color:#6a3e3e}array1{color}{color:#00} ==
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00}
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00});{color}
> {color:#00} } {color}{color:#80}else{color}{color:#00}
> {color}{color:#80}if{color}{color:#00}
> ({color}{color:#6a3e3e}array2{color}{color:#00} ==
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00}
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00});{color}
> {color:#00} }{color}
> {color:#80}final{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[]
> {color}{color:#6a3e3e}joinedArray{color}{color:#00} =
> {color}{color:#80}new{color}{color:#00}
> {color}{color:#80}boolean{color}{color:#00}[{color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}
> +
> {color}{color:#6a3e3e}array2{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}];{color}
> {color:#00}
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00},
> 0, {color}{color:#6a3e3e}joinedArray{color}{color:#00}, 0,
> {color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00});{color}
> {color:#00}
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00},
> 0, {color}{color:#6a3e3e}joinedArray{color}{color:#0
[jira] [Closed] (LANG-1639) Find enum using a predicate
[ https://issues.apache.org/jira/browse/LANG-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb closed LANG-1639. -- Resolution: Won't Do With the advent of Java8, it's possible to do this with not much code, for example: Arrays.stream(enumClass.getEnumConstants()).filter(predicate).findFirst() [1] [1] https://github.com/apache/commons-lang/pull/696#discussion_r1418285696 > Find enum using a predicate > --- > > Key: LANG-1639 > URL: https://issues.apache.org/jira/browse/LANG-1639 > Project: Commons Lang > Issue Type: New Feature > Components: lang.enums.* >Reporter: Bernhard Bonigl >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > `EnumUtils` supports finding an enum based on its name. However in my > experience it's often required to find an enum mapped by another value > related to the enum. To use a very simple example: Mapping a string input to > an enum, where the string does not match the enum name. > I propose adding a `getEnumByPredicate` method, that returns the first found > enum value matching a given predicate. Could also be expanded to return a > list of all matching values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-158) Illegal reflective access
[
https://issues.apache.org/jira/browse/CRYPTO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-158.
-
Resolution: Fixed
Fixed in {color:#22}b51442e5{color}
> Illegal reflective access
> -
>
> Key: CRYPTO-158
> URL: https://issues.apache.org/jira/browse/CRYPTO-158
> Project: Commons Crypto
> Issue Type: Bug
> Components: Cipher
>Affects Versions: 1.1.0
> Environment: Linux OpenJDK 15.0.2
>Reporter: Juan F Arjona
>Priority: Minor
>
> Getting this message:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.commons.crypto.stream.CryptoInputStream
> (.../BOOT-INF/lib/commons-crypto-1.1.0.jar!/) to method
> sun.nio.ch.DirectBuffer.cleaner()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.commons.crypto.stream.CryptoInputStream
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-136) Expose FIPS_mode_set() and FIPS_selftest() API
[ https://issues.apache.org/jira/browse/CRYPTO-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-136. - Resolution: Won't Do Needs to be redefined in terms of OpenSSL3 > Expose FIPS_mode_set() and FIPS_selftest() API > -- > > Key: CRYPTO-136 > URL: https://issues.apache.org/jira/browse/CRYPTO-136 > Project: Commons Crypto > Issue Type: Improvement > Components: Native >Reporter: Xiaodong Wang >Priority: Major > > Expose FIPS_mode_set() and FIPS_selftest() API > https://wiki.openssl.org/index.php/FIPS_mode_set() would allow applications > require FIPS compliance enter FIPS only mode, and run seft test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-158) Illegal reflective access
[ https://issues.apache.org/jira/browse/CRYPTO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791758#comment-17791758 ] Sebb commented on CRYPTO-158: - I have seen this regularly in tests using Java 11 on Ubuntu and macOs. The warning does not occur in java 17 or java 21; it looks like the request is just denied using ReflectiveOperationException. This is currently silently swallowed by the code. > Illegal reflective access > - > > Key: CRYPTO-158 > URL: https://issues.apache.org/jira/browse/CRYPTO-158 > Project: Commons Crypto > Issue Type: Bug > Components: Cipher >Affects Versions: 1.1.0 > Environment: Linux OpenJDK 15.0.2 >Reporter: Juan F Arjona >Priority: Minor > > Getting this message: > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.commons.crypto.stream.CryptoInputStream > (.../BOOT-INF/lib/commons-crypto-1.1.0.jar!/) to method > sun.nio.ch.DirectBuffer.cleaner() > WARNING: Please consider reporting this to the maintainers of > org.apache.commons.crypto.stream.CryptoInputStream > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-136) Expose FIPS_mode_set() and FIPS_selftest() API
[ https://issues.apache.org/jira/browse/CRYPTO-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790274#comment-17790274 ] Sebb commented on CRYPTO-136: - FIPS_mode was not enabled in 1.1, and has been removed in 3.x See [https://www.openssl.org/docs/man3.0/man3/EVP_default_properties_is_fips_enabled.html] for info > Expose FIPS_mode_set() and FIPS_selftest() API > -- > > Key: CRYPTO-136 > URL: https://issues.apache.org/jira/browse/CRYPTO-136 > Project: Commons Crypto > Issue Type: Improvement > Components: Native >Reporter: Xiaodong Wang >Priority: Major > > Expose FIPS_mode_set() and FIPS_selftest() API > https://wiki.openssl.org/index.php/FIPS_mode_set() would allow applications > require FIPS compliance enter FIPS only mode, and run seft test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-180) Need instructions for building distributions
[ https://issues.apache.org/jira/browse/CRYPTO-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-180. - Resolution: Fixed > Need instructions for building distributions > > > Key: CRYPTO-180 > URL: https://issues.apache.org/jira/browse/CRYPTO-180 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > Crypto includes some native code that needs to be built for multiple > different environments. > This needs to be documented -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-179) Crash on macOS with default crypto library
[ https://issues.apache.org/jira/browse/CRYPTO-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-179. - Resolution: Fixed > Crash on macOS with default crypto library > -- > > Key: CRYPTO-179 > URL: https://issues.apache.org/jira/browse/CRYPTO-179 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > Attempts to use the default crypto library on macOS crash with a message of > the form: > ".../bin/java is loading libcrypto in an unsafe way" > It is not possible to catch this error as the application is aborted. > It would be useful to be able to detect this in advance. > The method dlopen_preflight() performs the same checks as dlopen(), and > returns "no such file" for the default library (presumably it is in the > system cache). > To avoid unnecessary checks, we can assume that a non-default library does > not need to be checked. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-132) Instructions in BUILDING.txt don't work on MacOS
[
https://issues.apache.org/jira/browse/CRYPTO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-132.
-
Resolution: Fixed
Subsumed into CRYPTO-180
> Instructions in BUILDING.txt don't work on MacOS
>
>
> Key: CRYPTO-132
> URL: https://issues.apache.org/jira/browse/CRYPTO-132
> Project: Commons Crypto
> Issue Type: Bug
> Components: Build
>Reporter: Benedikt Ritter
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When using HomeBrew to link openssl with the --force, HomeBrew refuses to do
> this, indicating that our docs are not following best practices:
> {code}
> ~/w/a/c/commons-crypto git:(upstream ⚡ CRYPTO-131) 1A > brew link openssl
> --force
> Warning: Refusing to link: openssl
> Linking keg-only openssl means you may end up linking against the insecure,
> deprecated system OpenSSL while using the headers from Homebrew's openssl.
> Instead, pass the full include/library paths to your compiler e.g.:
> -I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib
> {code}
> Adapt the build so that it is no longer necessary to use link --force on MacOs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-120) Add instructions for native build at wiki
[ https://issues.apache.org/jira/browse/CRYPTO-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-120. - Resolution: Fixed Subsumed into CRYPTO-180 > Add instructions for native build at wiki > - > > Key: CRYPTO-120 > URL: https://issues.apache.org/jira/browse/CRYPTO-120 > Project: Commons Crypto > Issue Type: Bug >Reporter: Dapeng Sun >Assignee: Dapeng Sun >Priority: Major > > CRYPTO release built the same jar contained in the bin-zip with ALL of the > native libraries for Windows, Mac, and Linux, will add a wiki for it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-180) Need instructions for building distributions
Sebb created CRYPTO-180: --- Summary: Need instructions for building distributions Key: CRYPTO-180 URL: https://issues.apache.org/jira/browse/CRYPTO-180 Project: Commons Crypto Issue Type: Bug Reporter: Sebb Crypto includes some native code that needs to be built for multiple different environments. This needs to be documented -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-166) Library is reloaded multiple times
[ https://issues.apache.org/jira/browse/CRYPTO-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-166. - Resolution: Fixed > Library is reloaded multiple times > -- > > Key: CRYPTO-166 > URL: https://issues.apache.org/jira/browse/CRYPTO-166 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Sebb >Priority: Minor > > It looks like the JNI code keeps reloading the library, from which it then > has to retrieve the symbols it needs. > This is inefficient, and it means the handle reference count is increased > unnecessarily. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-166) Library is reloaded multiple times
[ https://issues.apache.org/jira/browse/CRYPTO-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789525#comment-17789525 ] Sebb commented on CRYPTO-166: - Library reloading was fixed by CRYPTO-168. However, the symbols are also fetched multiple times > Library is reloaded multiple times > -- > > Key: CRYPTO-166 > URL: https://issues.apache.org/jira/browse/CRYPTO-166 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Sebb >Priority: Minor > > It looks like the JNI code keeps reloading the library, from which it then > has to retrieve the symbols it needs. > This is inefficient, and it means the handle reference count is increased > unnecessarily. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CRYPTO-168) Centralise access to the crypto dynamic library
[ https://issues.apache.org/jira/browse/CRYPTO-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CRYPTO-168: Fix Version/s: 1.2.0 > Centralise access to the crypto dynamic library > --- > > Key: CRYPTO-168 > URL: https://issues.apache.org/jira/browse/CRYPTO-168 > Project: Commons Crypto > Issue Type: Improvement > Reporter: Sebb >Priority: Major > Fix For: 1.2.0 > > > There are currently 3 locations where the crypto dynamic library is loaded. > It would be better to have a single shared module to do this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-168) Centralise access to the crypto dynamic library
[ https://issues.apache.org/jira/browse/CRYPTO-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-168. - Resolution: Fixed > Centralise access to the crypto dynamic library > --- > > Key: CRYPTO-168 > URL: https://issues.apache.org/jira/browse/CRYPTO-168 > Project: Commons Crypto > Issue Type: Improvement > Reporter: Sebb >Priority: Major > Fix For: 1.2.0 > > > There are currently 3 locations where the crypto dynamic library is loaded. > It would be better to have a single shared module to do this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-168) Centralise access to the crypto dynamic library
[ https://issues.apache.org/jira/browse/CRYPTO-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789506#comment-17789506 ] Sebb commented on CRYPTO-168: - This was done in: https://github.com/apache/commons-crypto/commit/760ccfdd40ab1a80d72c8971ab505ec681f2ce62 > Centralise access to the crypto dynamic library > --- > > Key: CRYPTO-168 > URL: https://issues.apache.org/jira/browse/CRYPTO-168 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Major > > There are currently 3 locations where the crypto dynamic library is loaded. > It would be better to have a single shared module to do this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-179) Crash on macOS with default crypto library
Sebb created CRYPTO-179: --- Summary: Crash on macOS with default crypto library Key: CRYPTO-179 URL: https://issues.apache.org/jira/browse/CRYPTO-179 Project: Commons Crypto Issue Type: Bug Reporter: Sebb Attempts to use the default crypto library on macOS crash with a message of the form: ".../bin/java is loading libcrypto in an unsafe way" It is not possible to catch this error as the application is aborted. It would be useful to be able to detect this in advance. The method dlopen_preflight() performs the same checks as dlopen(), and returns "no such file" for the default library (presumably it is in the system cache). To avoid unnecessary checks, we can assume that a non-default library does not need to be checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-164) Add Support for OpenSSL 3.0.x
[ https://issues.apache.org/jira/browse/CRYPTO-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788678#comment-17788678 ] Sebb commented on CRYPTO-164: - Looks like this is already being tested on ubuntu-latest. > Add Support for OpenSSL 3.0.x > - > > Key: CRYPTO-164 > URL: https://issues.apache.org/jira/browse/CRYPTO-164 > Project: Commons Crypto > Issue Type: New Feature > Components: Native >Affects Versions: 1.1.0 >Reporter: Alex Remily >Priority: Major > > OpenSSL has released version 3.0.x. Commons Crypto should support this > release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-164) Add Support for OpenSSL 3.0.x
[ https://issues.apache.org/jira/browse/CRYPTO-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788571#comment-17788571 ] Sebb commented on CRYPTO-164: - Another issue is ensuring the native code can compile under 3.x, i.e. using header files from that version > Add Support for OpenSSL 3.0.x > - > > Key: CRYPTO-164 > URL: https://issues.apache.org/jira/browse/CRYPTO-164 > Project: Commons Crypto > Issue Type: New Feature > Components: Native >Affects Versions: 1.1.0 >Reporter: Alex Remily >Priority: Major > > OpenSSL has released version 3.0.x. Commons Crypto should support this > release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-164) Add Support for OpenSSL 3.0.x
[ https://issues.apache.org/jira/browse/CRYPTO-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788569#comment-17788569 ] Sebb commented on CRYPTO-164: - I'm concerned that the release notes for 3.0 mention some big changes, but hardly any changes were needed to the code (only two method renames). That suggests that there may be some missing tests. > Add Support for OpenSSL 3.0.x > - > > Key: CRYPTO-164 > URL: https://issues.apache.org/jira/browse/CRYPTO-164 > Project: Commons Crypto > Issue Type: New Feature > Components: Native >Affects Versions: 1.1.0 >Reporter: Alex Remily >Priority: Major > > OpenSSL has released version 3.0.x. Commons Crypto should support this > release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-115) Replace fixed DLL name #define with parameter?
[ https://issues.apache.org/jira/browse/CRYPTO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-115. - Resolution: Fixed Can now override the default name using the property commons.crypto.OpenSslNativeJn[ai] > Replace fixed DLL name #define with parameter? > -- > > Key: CRYPTO-115 > URL: https://issues.apache.org/jira/browse/CRYPTO-115 > Project: Commons Crypto > Issue Type: New Feature > Reporter: Sebb >Priority: Major > > At present, the OpenSSL dynamic library name is provided in the config.h > header file as conditional defines. > This is not particularly convenient as the default name for a given version > of the library may be different - for example on Windows, the DLL may be > released as libeay32.dll rather than libcrypto.dll. > And it would be useful to be able to use different versions of the library > without needing to copy/rename files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-159) JRE (x86) crash (EXCEPTION_ACCESS_VIOLATION)
[
https://issues.apache.org/jira/browse/CRYPTO-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-159.
-
Resolution: Fixed
Should be fixed in latest code.
If no, please open with suitable test case
> JRE (x86) crash (EXCEPTION_ACCESS_VIOLATION)
>
>
> Key: CRYPTO-159
> URL: https://issues.apache.org/jira/browse/CRYPTO-159
> Project: Commons Crypto
> Issue Type: Bug
> Components: Native
>Affects Versions: 1.1.0
>Reporter: Jeroen Markerink
>Priority: Major
> Attachments: hs_err_pid4640.log
>
>
> I have tested commons-crypto on Windows 7 and 10 and Java 32 bit with
> {code:java}
> java -cp commons-crypto-1.1.0.jar org.apache.commons.crypto.Crypto
> {code}
> but got a JRE crash . See attachment 'hs_err_pid4640.log'
> Additional info: Tested successfully with JRE 1.8.0_201 (x86_64):
> {code:java}
> java -cp commons-crypto-1.1.0.jar org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 16 2020
> OpenSSL library loaded OK, version: 0x1000215f
> OpenSSL library info: OpenSSL 1.0.2u 20 Dec 2019
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@4a574795
> Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@87aac27
> {code}
> {code:java}
> java -cp commons-crypto-1.1.0.jar org.apache.commons.crypto.Crypto
> Apache Commons Crypto 1.1.0
> Native code loaded OK: 1.1.0-SNAPSHOT
> Native name: Apache Commons Crypto
> Native built: Aug 16 2020
> OpenSSL library loaded OK, version: 0x101010bf
> OpenSSL library info: OpenSSL 1.1.1k 25 Mar 2021
> Random instance created OK:
> org.apache.commons.crypto.random.OpenSslCryptoRandom@4a574795
> Cipher AES/CTR/NoPadding instance created OK:
> org.apache.commons.crypto.cipher.OpenSslCipher@87aac27
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-169) Unable to load native library on Apple Silicon (M1 Mac)
[ https://issues.apache.org/jira/browse/CRYPTO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-169. - Resolution: Fixed AFAICT, this is fixed. Please re-open with a test that shows the issue if not > Unable to load native library on Apple Silicon (M1 Mac) > --- > > Key: CRYPTO-169 > URL: https://issues.apache.org/jira/browse/CRYPTO-169 > Project: Commons Crypto > Issue Type: Bug >Reporter: L. C. Hsieh >Priority: Major > Attachments: image-2023-10-21-17-51-41-260.png, > image-2023-10-21-17-52-02-237.png, image-2023-10-21-17-53-16-898.png, > image-2023-10-21-17-59-13-866.png, image-2023-10-22-23-58-57-254.png > > > Recently as trying to upgrade commons-crypto from 1.1.0 to 1.2.0 in Spark > (SPARK-45617), got the following error in one test: > ``` > [info] Cause: java.security.GeneralSecurityException: Native library is not > loaded > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.checkNative(OpenSslCryptoRandom.java:79) > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:65) > > [info] at java.base/java.lang.Class.forName0(Native Method) > > [info] at java.base/java.lang.Class.forName(Class.java:467) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByNameOrNull(ReflectionUtils.java:93) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByName(ReflectionUtils.java:64) > [info] at > org.apache.commons.crypto.random.CryptoRandomFactory.getCryptoRandom(CryptoRandomFactory.java:189) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createInitializationVector(CryptoStreamUtils.scala:138) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createCryptoOutputStream(CryptoStreamUtils.scala:56) > [info] at > org.apache.spark.serializer.SerializerManager.$anonfun$wrapForEncryption$3(SerializerManager.scala:151) > > ``` > I did a quick check. commons-crypto-1.2.0.jar only contain x86_64 Mac native > library, it doesn't provide pre-built native library for Apple Silicon. > But I also checked commons-crypto-1.1.0.jar which Spark uses currently. It > also doesn't provide native library for Apple Silicon. > Since they both don't contain native library for Apple Silicon, why > commons-crypto-1.2.0 doesn't work and what makes the difference between > commons-crypto-1.1.0 and commons-crypto-1.2.0? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-147) Link in OpenSslJnaCipher code or remove as option for OpenSslCipher
[ https://issues.apache.org/jira/browse/CRYPTO-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-147. - Resolution: Fixed This was fixed by CRYPTO-177 > Link in OpenSslJnaCipher code or remove as option for OpenSslCipher > --- > > Key: CRYPTO-147 > URL: https://issues.apache.org/jira/browse/CRYPTO-147 > Project: Commons Crypto > Issue Type: Wish >Affects Versions: 1.0.0 > Environment: All supported environments. >Reporter: Geoffrey Blake >Priority: Minor > > It appears while the JNA code is present, it will never actually be used by > the common-crypto library when a user asks for a provider from the list of > Cipher providers. Only the OpenSslNative JNI code or the JCE provider will > be selected. The OpenSslJnaCipher class should be added to > CryptoCipherFactory.CipherProvider as an option. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-162) openSslCipher support engine
[
https://issues.apache.org/jira/browse/CRYPTO-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788530#comment-17788530
]
Sebb commented on CRYPTO-162:
-
It's not at all clear what is wanted here.
> openSslCipher support engine
>
>
> Key: CRYPTO-162
> URL: https://issues.apache.org/jira/browse/CRYPTO-162
> Project: Commons Crypto
> Issue Type: New Feature
> Components: Cipher
>Reporter: wenweijian
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The engine is the hardware or software implementation used for performing
> cryptographic operations.
>
> Assume we have a hardware device with a super fast implementation of AES. Now
> when we use AES encryption we can set the engine to that hardware device
> (instead of {{{}NULL{}}}), which means that the operations are now computed
> by the hardware device instead of the default OpenSSL software layer.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-156) Common Class Padding, Transform and AlgorithmMode
[
https://issues.apache.org/jira/browse/CRYPTO-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-156.
-
Resolution: Abandoned
AFAICT this has been abandoned
> Common Class Padding, Transform and AlgorithmMode
> -
>
> Key: CRYPTO-156
> URL: https://issues.apache.org/jira/browse/CRYPTO-156
> Project: Commons Crypto
> Issue Type: Improvement
> Components: Cipher
>Affects Versions: 1.1.0
>Reporter: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> In order to avoid duplicate code and try to unify the transformation of the
> token i think it's necessary create the next class/enum:
> * {{OpenSslTransform}} --> Utility code for dealing with different algorithm
> types
> * {{OpenSslPadding}} --> Containg the enumeration of Cipher Algorithm Padding
> * {{OpenSslAlgorithmMode}} --> Enumeration of Algorithm Mode.
> [https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/cipher/OpenSsl.java#L208]
>
> [https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/jna/OpenSslJnaCipher.java#L422]
>
> [https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/cipher/OpenSsl.java#L47]
>
> [https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/jna/OpenSslJnaCipher.java#L399]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-175) JNA tests rely on JNI code
[ https://issues.apache.org/jira/browse/CRYPTO-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-175. - Resolution: Fixed > JNA tests rely on JNI code > -- > > Key: CRYPTO-175 > URL: https://issues.apache.org/jira/browse/CRYPTO-175 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > The JNA tests rely on being able to use the JNI code. > For example, this JNA test works: > mvn test -Dtest=CbcNoPaddingCipherJnaStreamTest > However the following test fails: > mvn test -Dtest=CbcNoPaddingCipherJnaStreamTest -Djni.library.path=/tmp/ > with > Caused by: java.lang.UnsatisfiedLinkError: Cannot load libcrypto.dylib > (dlopen(/tmp/libcrypto.dylib, 0x0009): tried: '/tmp/libcrypto.dylib' (no such > file), '/private/tmp/libcrypto.dylib' (no such file))! > I suspect this may be due to re-using some of the jni test classes. > I suppose it is possible that the loading of the JNI classes is incidental, > and maybe the tests don't actually invoke them, but the tests ought to run > even if JNI is not available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-164) Add Support for OpenSSL 3.0.x
[ https://issues.apache.org/jira/browse/CRYPTO-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788186#comment-17788186 ] Sebb commented on CRYPTO-164: - Tests currently run under OpenSSL 3.0.x. More tests are likely needed. > Add Support for OpenSSL 3.0.x > - > > Key: CRYPTO-164 > URL: https://issues.apache.org/jira/browse/CRYPTO-164 > Project: Commons Crypto > Issue Type: New Feature > Components: Native >Affects Versions: 1.1.0 >Reporter: Alex Remily >Priority: Major > > OpenSSL has released version 3.0.x. Commons Crypto should support this > release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-169) Unable to load native library on Apple Silicon (M1 Mac)
[ https://issues.apache.org/jira/browse/CRYPTO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788185#comment-17788185 ] Sebb commented on CRYPTO-169: - OpenSslCryptoRandom static block issue reported as CRYPTO-178; now fixed > Unable to load native library on Apple Silicon (M1 Mac) > --- > > Key: CRYPTO-169 > URL: https://issues.apache.org/jira/browse/CRYPTO-169 > Project: Commons Crypto > Issue Type: Bug >Reporter: L. C. Hsieh >Priority: Major > Attachments: image-2023-10-21-17-51-41-260.png, > image-2023-10-21-17-52-02-237.png, image-2023-10-21-17-53-16-898.png, > image-2023-10-21-17-59-13-866.png, image-2023-10-22-23-58-57-254.png > > > Recently as trying to upgrade commons-crypto from 1.1.0 to 1.2.0 in Spark > (SPARK-45617), got the following error in one test: > ``` > [info] Cause: java.security.GeneralSecurityException: Native library is not > loaded > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.checkNative(OpenSslCryptoRandom.java:79) > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:65) > > [info] at java.base/java.lang.Class.forName0(Native Method) > > [info] at java.base/java.lang.Class.forName(Class.java:467) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByNameOrNull(ReflectionUtils.java:93) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByName(ReflectionUtils.java:64) > [info] at > org.apache.commons.crypto.random.CryptoRandomFactory.getCryptoRandom(CryptoRandomFactory.java:189) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createInitializationVector(CryptoStreamUtils.scala:138) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createCryptoOutputStream(CryptoStreamUtils.scala:56) > [info] at > org.apache.spark.serializer.SerializerManager.$anonfun$wrapForEncryption$3(SerializerManager.scala:151) > > ``` > I did a quick check. commons-crypto-1.2.0.jar only contain x86_64 Mac native > library, it doesn't provide pre-built native library for Apple Silicon. > But I also checked commons-crypto-1.1.0.jar which Spark uses currently. It > also doesn't provide native library for Apple Silicon. > Since they both don't contain native library for Apple Silicon, why > commons-crypto-1.2.0 doesn't work and what makes the difference between > commons-crypto-1.1.0 and commons-crypto-1.2.0? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CRYPTO-178) OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded
[ https://issues.apache.org/jira/browse/CRYPTO-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CRYPTO-178: Description: OpenSslCryptoRandom.isNativeCodeEnabled() currently throws an Exception if the native cannot be found. This is wrong, because the static method should return false if native cannot be enabled (e.g. missing SSL dynamic library or wrong type) was:OpenSslCryptoRandom.isNativeCodeEnabled() currently throws an Exception if the native cannout be found > OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded > > > Key: CRYPTO-178 > URL: https://issues.apache.org/jira/browse/CRYPTO-178 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > OpenSslCryptoRandom.isNativeCodeEnabled() currently throws an Exception if > the native cannot be found. > This is wrong, because the static method should return false if native cannot > be enabled (e.g. missing SSL dynamic library or wrong type) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-178) OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded
[ https://issues.apache.org/jira/browse/CRYPTO-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-178. - Resolution: Fixed Removed check from static block > OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded > > > Key: CRYPTO-178 > URL: https://issues.apache.org/jira/browse/CRYPTO-178 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > OpenSslCryptoRandom.isNativeCodeEnabled() currently throws an Exception if > the native cannout be found -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-178) OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded
[ https://issues.apache.org/jira/browse/CRYPTO-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787920#comment-17787920 ] Sebb commented on CRYPTO-178: - For example, docker test using Ubuntu and invalid library name: $ docker compose -f src/docker/docker-compose.yaml run crypto mvn surefire:test -Dtest=OpenSslCryptoRandomTest -Djni.library.name=___ [+] Building 0.0s (0/0) docker:desktop-linux [+] Building 0.0s (0/0) docker:desktop-linux Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39) Maven home: /opt/maven Java version: 1.8.0_382, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux", version: "6.4.16-linuxkit", arch: "amd64", family: "unix" [INFO] Scanning for projects... [INFO] [INFO] -< org.apache.commons:commons-crypto >-- [INFO] Building Apache Commons Crypto 1.2.1-SNAPSHOT [INFO] from pom.xml [INFO] [ jar ]- [INFO] [INFO] --- maven-surefire-plugin:3.1.2:test (default-cli) @ commons-crypto --- [INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider [INFO] [INFO] --- [INFO] T E S T S [INFO] --- [INFO] Running org.apache.commons.crypto.random.OpenSslCryptoRandomTest [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.101 s <<< FAILURE! -- in org.apache.commons.crypto.random.OpenSslCryptoRandomTest [ERROR] org.apache.commons.crypto.random.OpenSslCryptoRandomTest -- Time elapsed: 0.101 s <<< ERROR! java.lang.ExceptionInInitializerError at org.apache.commons.crypto.random.OpenSslCryptoRandomTest.beforeAll(OpenSslCryptoRandomTest.java:34) at java.lang.reflect.Method.invoke(Method.java:498) at java.util.ArrayList.forEach(ArrayList.java:1259) Caused by: java.lang.IllegalStateException: java.security.GeneralSecurityException: Native library could not be initialized at org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:67) ... 3 more Caused by: java.security.GeneralSecurityException: Native library could not be initialized at org.apache.commons.crypto.random.OpenSslCryptoRandom.checkNative(OpenSslCryptoRandom.java:77) at org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:65) ... 3 more Caused by: java.lang.UnsatisfiedLinkError: Cannot load '___' (___: cannot open shared object file: No such file or directory)! at org.apache.commons.crypto.random.OpenSslCryptoRandomNative.initSR(Native Method) at org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:54) ... 3 more [INFO] [INFO] Results: [INFO] [ERROR] Errors: [ERROR] OpenSslCryptoRandomTest.beforeAll:34 ExceptionInInitializer [INFO] [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 [INFO] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.202 s [INFO] Finished at: 2023-11-20T09:53:01Z [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.1.2:test (default-cli) on project commons-crypto: [ERROR] [ERROR] Please refer to /home/crypto/target/surefire-reports for the individual test results. [ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException $ > OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded > > > Key: CRYPTO-178 > URL: https://issues.apache.org/jira/browse/CRYPTO-178 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > OpenSslCryptoR
[jira] [Created] (CRYPTO-178) OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded
Sebb created CRYPTO-178: --- Summary: OpenSslCryptoRandom.isNativeCodeEnabled() throws if library cannot be loaded Key: CRYPTO-178 URL: https://issues.apache.org/jira/browse/CRYPTO-178 Project: Commons Crypto Issue Type: Bug Reporter: Sebb OpenSslCryptoRandom.isNativeCodeEnabled() currently throws an Exception if the native cannout be found -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-169) Unable to load native library on Apple Silicon (M1 Mac)
[ https://issues.apache.org/jira/browse/CRYPTO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787684#comment-17787684 ] Sebb commented on CRYPTO-169: - I think there is a problem with the recent changes to OpenSslCryptoRandom. It seems wrong for the static block to raise an Exception. This means that the method OpenSslCryptoRandom.isNativeCodeEnabled() cannot be used if the class does not load. Rather than checking for errors in the static block, they should be checked by the methods of the class as necessary. > Unable to load native library on Apple Silicon (M1 Mac) > --- > > Key: CRYPTO-169 > URL: https://issues.apache.org/jira/browse/CRYPTO-169 > Project: Commons Crypto > Issue Type: Bug >Reporter: L. C. Hsieh >Priority: Major > Attachments: image-2023-10-21-17-51-41-260.png, > image-2023-10-21-17-52-02-237.png, image-2023-10-21-17-53-16-898.png, > image-2023-10-21-17-59-13-866.png, image-2023-10-22-23-58-57-254.png > > > Recently as trying to upgrade commons-crypto from 1.1.0 to 1.2.0 in Spark > (SPARK-45617), got the following error in one test: > ``` > [info] Cause: java.security.GeneralSecurityException: Native library is not > loaded > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.checkNative(OpenSslCryptoRandom.java:79) > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:65) > > [info] at java.base/java.lang.Class.forName0(Native Method) > > [info] at java.base/java.lang.Class.forName(Class.java:467) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByNameOrNull(ReflectionUtils.java:93) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByName(ReflectionUtils.java:64) > [info] at > org.apache.commons.crypto.random.CryptoRandomFactory.getCryptoRandom(CryptoRandomFactory.java:189) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createInitializationVector(CryptoStreamUtils.scala:138) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createCryptoOutputStream(CryptoStreamUtils.scala:56) > [info] at > org.apache.spark.serializer.SerializerManager.$anonfun$wrapForEncryption$3(SerializerManager.scala:151) > > ``` > I did a quick check. commons-crypto-1.2.0.jar only contain x86_64 Mac native > library, it doesn't provide pre-built native library for Apple Silicon. > But I also checked commons-crypto-1.1.0.jar which Spark uses currently. It > also doesn't provide native library for Apple Silicon. > Since they both don't contain native library for Apple Silicon, why > commons-crypto-1.2.0 doesn't work and what makes the difference between > commons-crypto-1.1.0 and commons-crypto-1.2.0? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-177) Cipher and Random Factory classes don't include JNA
[ https://issues.apache.org/jira/browse/CRYPTO-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-177. - Resolution: Fixed > Cipher and Random Factory classes don't include JNA > --- > > Key: CRYPTO-177 > URL: https://issues.apache.org/jira/browse/CRYPTO-177 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The CryptoCipherFactory and CryptoRandomFactory classes don't include JNA > options -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CRYPTO-177) Cipher and Random Factory classes don't include JNA
[ https://issues.apache.org/jira/browse/CRYPTO-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CRYPTO-177: Summary: Cipher and Random Factory classes don't include JNA (was: Cipher and Random Factor classes don't include JNA) > Cipher and Random Factory classes don't include JNA > --- > > Key: CRYPTO-177 > URL: https://issues.apache.org/jira/browse/CRYPTO-177 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The CryptoCipherFactory and CryptoRandomFactory classes don't include JNA > options -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-171) OpenSslCryptoRandomNative.c uses syscall(2) which is deprecated on macos M1
[ https://issues.apache.org/jira/browse/CRYPTO-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-171. - Resolution: Fixed No longer needed, now that 1.0.x is no longer supported > OpenSslCryptoRandomNative.c uses syscall(2) which is deprecated on macos M1 > --- > > Key: CRYPTO-171 > URL: https://issues.apache.org/jira/browse/CRYPTO-171 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > Sample warning: > [exec] > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:219:25: > warning: 'syscall' is deprecated: first deprecated in macOS 10.12 - > syscall(2) is unsupported; please switch to a supported interface. For > SYS_kdebug_trace use kdebug_signpost(). [-Wdeprecated-declarations] > [INFO] [exec] return (unsigned long)syscall(SYS_gettid); > [INFO] [exec] ^ > [INFO] [exec] > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/unistd.h:746:6: > note: 'syscall' has been explicitly marked deprecated here > [INFO] [exec] int syscall(int, ...); > [INFO] [exec] ^ > [INFO] [exec] 1 warning generated. > It's not obvious what the replacement should be. > However, AFAICT the code is only used if OpenSSL version is < VERSION_1_1_X. > So perhaps that code and its callers could be dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-173) docker build does not work on macOS M1
[ https://issues.apache.org/jira/browse/CRYPTO-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-173. - Resolution: Fixed > docker build does not work on macOS M1 > -- > > Key: CRYPTO-173 > URL: https://issues.apache.org/jira/browse/CRYPTO-173 > Project: Commons Crypto > Issue Type: Bug > Reporter: Sebb >Priority: Major > > The Docker build no longer works on macOS M1, because it cannot find > 'gcc-aarch64-linux-gnu' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-177) Cipher and Random Factor classes don't include JNA
Sebb created CRYPTO-177: --- Summary: Cipher and Random Factor classes don't include JNA Key: CRYPTO-177 URL: https://issues.apache.org/jira/browse/CRYPTO-177 Project: Commons Crypto Issue Type: Bug Reporter: Sebb The CryptoCipherFactory and CryptoRandomFactory classes don't include JNA options -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-176) Drop dependency on Commons IO?
[ https://issues.apache.org/jira/browse/CRYPTO-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-176. - Resolution: Won't Fix > Drop dependency on Commons IO? > -- > > Key: CRYPTO-176 > URL: https://issues.apache.org/jira/browse/CRYPTO-176 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > Commons IO is currently a dependency, but the only reference is to a single > method: > IOUtils.contentEquals > Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-176) Drop dependency on Commons IO?
[ https://issues.apache.org/jira/browse/CRYPTO-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784623#comment-17784623 ] Sebb commented on CRYPTO-176: - There is bound to be some code duplication across components, so I don't see that as an issue of itself. It is a balancing act between not having unnecessary dependencies and having large quantities of duplicated code. > Drop dependency on Commons IO? > -- > > Key: CRYPTO-176 > URL: https://issues.apache.org/jira/browse/CRYPTO-176 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > Commons IO is currently a dependency, but the only reference is to a single > method: > IOUtils.contentEquals > Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-176) Drop dependency on Commons IO?
[ https://issues.apache.org/jira/browse/CRYPTO-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784514#comment-17784514 ] Sebb commented on CRYPTO-176: - Note that there are already versions of readFully and closeQuietly in utils.IoUtils. > Drop dependency on Commons IO? > -- > > Key: CRYPTO-176 > URL: https://issues.apache.org/jira/browse/CRYPTO-176 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > Commons IO is currently a dependency, but the only reference is to a single > method: > IOUtils.contentEquals > Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CRYPTO-176) Drop dependency on Commons IO?
[ https://issues.apache.org/jira/browse/CRYPTO-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784514#comment-17784514 ] Sebb edited comment on CRYPTO-176 at 11/9/23 3:29 PM: -- Note that there are already versions of readFully and closeQuietly in utils.IoUtils. So if it is decided to keep the dependency, it would make sense to drop the local copies in favour of Commons IO was (Author: s...@apache.org): Note that there are already versions of readFully and closeQuietly in utils.IoUtils. > Drop dependency on Commons IO? > -- > > Key: CRYPTO-176 > URL: https://issues.apache.org/jira/browse/CRYPTO-176 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > Commons IO is currently a dependency, but the only reference is to a single > method: > IOUtils.contentEquals > Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-176) Drop dependency on Commons IO?
Sebb created CRYPTO-176: --- Summary: Drop dependency on Commons IO? Key: CRYPTO-176 URL: https://issues.apache.org/jira/browse/CRYPTO-176 Project: Commons Crypto Issue Type: Improvement Reporter: Sebb Commons IO is currently a dependency, but the only reference is to a single method: IOUtils.contentEquals Consider whether to replace the dependency with local code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-175) JNA tests rely on JNI code
Sebb created CRYPTO-175: --- Summary: JNA tests rely on JNI code Key: CRYPTO-175 URL: https://issues.apache.org/jira/browse/CRYPTO-175 Project: Commons Crypto Issue Type: Bug Reporter: Sebb The JNA tests rely on being able to use the JNI code. For example, this JNA test works: mvn test -Dtest=CbcNoPaddingCipherJnaStreamTest However the following test fails: mvn test -Dtest=CbcNoPaddingCipherJnaStreamTest -Djni.library.path=/tmp/ with Caused by: java.lang.UnsatisfiedLinkError: Cannot load libcrypto.dylib (dlopen(/tmp/libcrypto.dylib, 0x0009): tried: '/tmp/libcrypto.dylib' (no such file), '/private/tmp/libcrypto.dylib' (no such file))! I suspect this may be due to re-using some of the jni test classes. I suppose it is possible that the loading of the JNI classes is incidental, and maybe the tests don't actually invoke them, but the tests ought to run even if JNI is not available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-174) Allow override of SSL library name
[ https://issues.apache.org/jira/browse/CRYPTO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-174. - Resolution: Fixed > Allow override of SSL library name > -- > > Key: CRYPTO-174 > URL: https://issues.apache.org/jira/browse/CRYPTO-174 > Project: Commons Crypto > Issue Type: New Feature > Reporter: Sebb >Assignee: Sebb >Priority: Major > > Windows seems to install all the crypto libraries in C:\Windows\SYSTEM32. > The default has the name libcrypto.dll, and alternates may have names such as > libcrypto-1_1-x64.dll. > This is different from Unix and macOS, where different versions are stored in > different directories. The default library name is a softlink to the > versioned name, so there is no need to change the name. > This means allowing for the override of both the JNI name and JNA name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-174) Allow override of SSL library name
Sebb created CRYPTO-174: --- Summary: Allow override of SSL library name Key: CRYPTO-174 URL: https://issues.apache.org/jira/browse/CRYPTO-174 Project: Commons Crypto Issue Type: New Feature Reporter: Sebb Assignee: Sebb Windows seems to install all the crypto libraries in C:\Windows\SYSTEM32. The default has the name libcrypto.dll, and alternates may have names such as libcrypto-1_1-x64.dll. This is different from Unix and macOS, where different versions are stored in different directories. The default library name is a softlink to the versioned name, so there is no need to change the name. This means allowing for the override of both the JNI name and JNA name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-167) Cannot use env to report missing env!
[
https://issues.apache.org/jira/browse/CRYPTO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-167.
-
Resolution: Fixed
> Cannot use env to report missing env!
> -
>
> Key: CRYPTO-167
> URL: https://issues.apache.org/jira/browse/CRYPTO-167
> Project: Commons Crypto
> Issue Type: Bug
> Reporter: Sebb
>Priority: Major
>
> There are several places (e.g. [1]) where the code does the following or
> similar:
> {code}
> if (!env || !handle) {
> THROW(env, "java/lang/InternalError", NULL);
> return NULL;
> }
> {code}
> This does not make sense, as the THROW macro tries to use the env variable to
> report the problem. This will cause a crash which may be hard to decipher. If
> the env parameter is NULL, different action should be taken if possible.
> [1]
> https://github.com/apache/commons-crypto/blob/5bb858cbcffb3aff915a6928e7761d5f33d56b6b/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h#L84
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CRYPTO-167) Cannot use env to report missing env!
[
https://issues.apache.org/jira/browse/CRYPTO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782940#comment-17782940
]
Sebb commented on CRYPTO-167:
-
I now think this issue is wrong; the problem is that the code should not be
checking for a missing env.
The check is only done for calls to methods internal to the native code via the
macros LOAD_DYNAMIC_SYMBOL and LOAD_DYNAMIC_SYMBOL_FALLBACK.
> Cannot use env to report missing env!
> -
>
> Key: CRYPTO-167
> URL: https://issues.apache.org/jira/browse/CRYPTO-167
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are several places (e.g. [1]) where the code does the following or
> similar:
> {code}
> if (!env || !handle) {
> THROW(env, "java/lang/InternalError", NULL);
> return NULL;
> }
> {code}
> This does not make sense, as the THROW macro tries to use the env variable to
> report the problem. This will cause a crash which may be hard to decipher. If
> the env parameter is NULL, different action should be taken if possible.
> [1]
> https://github.com/apache/commons-crypto/blob/5bb858cbcffb3aff915a6928e7761d5f33d56b6b/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h#L84
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-172) Add support for Linux-riscv64
[ https://issues.apache.org/jira/browse/CRYPTO-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-172. - Resolution: Fixed > Add support for Linux-riscv64 > - > > Key: CRYPTO-172 > URL: https://issues.apache.org/jira/browse/CRYPTO-172 > Project: Commons Crypto > Issue Type: Improvement > Components: Build >Reporter: Ludovic Henry >Priority: Major > > Java supports RISC-V since version 19. Given Apache Common Crypto is a > commonly used library in the Java ecosystem, it's important for it to support > RISC-V as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-170) Test fails with "java is loading libcrypto in an unsafe way" on macos-11/Java21
[ https://issues.apache.org/jira/browse/CRYPTO-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-170. - Resolution: Fixed Using the appropriate definition for jni.library.path (and the same for jna.library.path) solves the issue > Test fails with "java is loading libcrypto in an unsafe way" on > macos-11/Java21 > --- > > Key: CRYPTO-170 > URL: https://issues.apache.org/jira/browse/CRYPTO-170 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > Test fails with "java is loading libcrypto in an unsafe way" on macos-11 > using Java21 > This is using: > Java version: 21.0.1, vendor: Eclipse Adoptium, runtime: > /Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.1-12.0.LTS/x64/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" > Makefile settings: > === OS_NAME=Mac OS_ARCH=x86_64 os_arch=Mac-x86_64 === > The workflow has been adjusted to allow for this failure -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-173) docker build does not work on macOS M1
Sebb created CRYPTO-173: --- Summary: docker build does not work on macOS M1 Key: CRYPTO-173 URL: https://issues.apache.org/jira/browse/CRYPTO-173 Project: Commons Crypto Issue Type: Bug Reporter: Sebb The Docker build no longer works on macOS M1, because it cannot find 'gcc-aarch64-linux-gnu' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-170) Test fails with "java is loading libcrypto in an unsafe way" on macos-11/Java21
[ https://issues.apache.org/jira/browse/CRYPTO-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781831#comment-17781831 ] Sebb commented on CRYPTO-170: - It looks like this can be avoided by defining jni.library.path and jna.library.path to point to a versioned installation of OpenSSL, i.e. one where libcryto.dylib is symlinked to a versioned file, e.g. libcrypto.dylib -> libcrypto.1.1.dylib > Test fails with "java is loading libcrypto in an unsafe way" on > macos-11/Java21 > --- > > Key: CRYPTO-170 > URL: https://issues.apache.org/jira/browse/CRYPTO-170 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > Test fails with "java is loading libcrypto in an unsafe way" on macos-11 > using Java21 > This is using: > Java version: 21.0.1, vendor: Eclipse Adoptium, runtime: > /Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.1-12.0.LTS/x64/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" > Makefile settings: > === OS_NAME=Mac OS_ARCH=x86_64 os_arch=Mac-x86_64 === > The workflow has been adjusted to allow for this failure -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-133) OpenSslCryptoRandomNative.nextRandBytes not thread safe
[
https://issues.apache.org/jira/browse/CRYPTO-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-133.
-
Resolution: Feedback Received
Seems to be resolved
> OpenSslCryptoRandomNative.nextRandBytes not thread safe
> ---
>
> Key: CRYPTO-133
> URL: https://issues.apache.org/jira/browse/CRYPTO-133
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Hendrik Saly
>Priority: Major
>
> Seems that AbstractRandomTest.testRandomBytesMultiThreaded is failing for
> OpenSslCryptoRandomNative.nextRandBytes.
> Testcase throws exceptions like
> {code}
> java.lang.IllegalArgumentException: The nextRandBytes method failed
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandom.nextBytes(OpenSslCryptoRandom.java:108)
> at
> org.apache.commons.crypto.random.AbstractRandomTest.checkRandomBytes(AbstractRandomTest.java:94)
> at
> org.apache.commons.crypto.random.AbstractRandomTest.access$000(AbstractRandomTest.java:30)
> at
> org.apache.commons.crypto.random.AbstractRandomTest$1.run(AbstractRandomTest.java:63)
> {code}
> When adding a 'synchronized' modifier to
> OpenSslCryptoRandomNative.nextRandBytes it works.
> So IMHO there are two bugs that need to be resolved:
> 1) fix testcase AbstractRandomTest.testRandomBytesMultiThreaded in that way
> that it fails when exception are thrown
> 2) fix OpenSslCryptoRandomNative.nextRandBytes no be thread safe (of course
> not by adding 'synchronized', seems like locks_setup() is broken somehow in
> https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c#L299
>
> The testcase can be fixed with something like this
> {code}
> @Test(timeout = 12)
> public void testRandomBytesMultiThreaded() throws Exception {
> final int threadCount = 100;
> final AtomicBoolean hasErrors = new AtomicBoolean();
> try (final CryptoRandom random = getCryptoRandom()) {
> final List threads = new ArrayList<>(threadCount);
> for (int i = 0; i < threadCount; i++) {
> Thread t = new Thread(new Runnable() {
> @Override
> public void run() {
> try {
>
> checkRandomBytes(random, 10);
>
> checkRandomBytes(random, 1000);
>
> checkRandomBytes(random, 10);
> } catch (Exception e) {
> hasErrors.set(true);
> e.printStackTrace();
> }
> }
> });
> t.start();
> threads.add(t);
> }
> for (Thread t : threads) {
> if (!t.getState().equals(State.NEW)) {
> t.join();
> }
> }
>
> if(hasErrors.get()) {
> Assert.fail();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-150) An illegal reflective access operation has occurred
[ https://issues.apache.org/jira/browse/CRYPTO-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-150. - Resolution: Duplicate > An illegal reflective access operation has occurred > --- > > Key: CRYPTO-150 > URL: https://issues.apache.org/jira/browse/CRYPTO-150 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.0.0 > Environment: Intellij w/ maven v3.6.3 >Reporter: DongKeun Lee >Priority: Minor > Attachments: Screen Shot 2020-08-18 at 2.46.20 PM.png > > > I tried to follow the apache commons - Usage of stream encryption/decryption > sample code, and the attached error occurred. > I'm not sure this is whether serious or not -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-144) Illegal reflective access by org.apache.commons.crypto.stream.CryptoInputStream
[
https://issues.apache.org/jira/browse/CRYPTO-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-144.
-
Resolution: Duplicate
> Illegal reflective access by
> org.apache.commons.crypto.stream.CryptoInputStream
> ---
>
> Key: CRYPTO-144
> URL: https://issues.apache.org/jira/browse/CRYPTO-144
> Project: Commons Crypto
> Issue Type: Bug
> Components: Stream
>Affects Versions: 1.0.0
> Environment: Ubuntu Xenial, Java 11.0.2 OpenJDK 64-Bit
>Reporter: Dmytro Titov
>Priority: Minor
>
> {code:java}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.commons.crypto.stream.CryptoInputStream (/crypt4gh.jar) to
> method sun.nio.ch.DirectBuffer.cleaner()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.commons.crypto.stream.CryptoInputStream
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {code}
> This happens when used on Java 9+. With Java 8 this warning doesn't seem to
> occur.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CRYPTO-158) Illegal reflective access
[ https://issues.apache.org/jira/browse/CRYPTO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780738#comment-17780738 ] Sebb commented on CRYPTO-158: - The class CryptoInputStream does currently use reflection to deallocate the buffers. AFAICT there is no supported way to do this. It looks like one has to wait for GC to free the memory. It might be sufficient to change the freeDirectBuffer method to use clear() instead. > Illegal reflective access > - > > Key: CRYPTO-158 > URL: https://issues.apache.org/jira/browse/CRYPTO-158 > Project: Commons Crypto > Issue Type: Bug > Components: Cipher >Affects Versions: 1.1.0 > Environment: Linux OpenJDK 15.0.2 >Reporter: Juan F Arjona >Priority: Minor > > Getting this message: > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.commons.crypto.stream.CryptoInputStream > (.../BOOT-INF/lib/commons-crypto-1.1.0.jar!/) to method > sun.nio.ch.DirectBuffer.cleaner() > WARNING: Please consider reporting this to the maintainers of > org.apache.commons.crypto.stream.CryptoInputStream > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-166) Library is reloaded multiple times
[ https://issues.apache.org/jira/browse/CRYPTO-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780733#comment-17780733 ] Sebb commented on CRYPTO-166: - I wonder if this is related to CRYPTO-170? > Library is reloaded multiple times > -- > > Key: CRYPTO-166 > URL: https://issues.apache.org/jira/browse/CRYPTO-166 > Project: Commons Crypto > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Sebb >Priority: Minor > > It looks like the JNI code keeps reloading the library, from which it then > has to retrieve the symbols it needs. > This is inefficient, and it means the handle reference count is increased > unnecessarily. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-167) Cannot use env to report missing env!
[
https://issues.apache.org/jira/browse/CRYPTO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780732#comment-17780732
]
Sebb commented on CRYPTO-167:
-
[~adbhonsle] If you have a GitHub account, feel free to raise a PR to fix the
issue.
Alternatively, attach a patch to this issue.
> Cannot use env to report missing env!
> -
>
> Key: CRYPTO-167
> URL: https://issues.apache.org/jira/browse/CRYPTO-167
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are several places (e.g. [1]) where the code does the following or
> similar:
> {code}
> if (!env || !handle) {
> THROW(env, "java/lang/InternalError", NULL);
> return NULL;
> }
> {code}
> This does not make sense, as the THROW macro tries to use the env variable to
> report the problem. This will cause a crash which may be hard to decipher. If
> the env parameter is NULL, different action should be taken if possible.
> [1]
> https://github.com/apache/commons-crypto/blob/5bb858cbcffb3aff915a6928e7761d5f33d56b6b/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h#L84
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CRYPTO-171) OpenSslCryptoRandomNative.c uses syscall(2) which is deprecated on macos M1
Sebb created CRYPTO-171: --- Summary: OpenSslCryptoRandomNative.c uses syscall(2) which is deprecated on macos M1 Key: CRYPTO-171 URL: https://issues.apache.org/jira/browse/CRYPTO-171 Project: Commons Crypto Issue Type: Bug Reporter: Sebb Sample warning: [exec] src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:219:25: warning: 'syscall' is deprecated: first deprecated in macOS 10.12 - syscall(2) is unsupported; please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost(). [-Wdeprecated-declarations] [INFO] [exec] return (unsigned long)syscall(SYS_gettid); [INFO] [exec] ^ [INFO] [exec] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/unistd.h:746:6: note: 'syscall' has been explicitly marked deprecated here [INFO] [exec] int syscall(int, ...); [INFO] [exec] ^ [INFO] [exec] 1 warning generated. It's not obvious what the replacement should be. However, AFAICT the code is only used if OpenSSL version is < VERSION_1_1_X. So perhaps that code and its callers could be dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CRYPTO-170) Test fails with "java is loading libcrypto in an unsafe way" on macos-11/Java21
Sebb created CRYPTO-170: --- Summary: Test fails with "java is loading libcrypto in an unsafe way" on macos-11/Java21 Key: CRYPTO-170 URL: https://issues.apache.org/jira/browse/CRYPTO-170 Project: Commons Crypto Issue Type: Bug Reporter: Sebb Test fails with "java is loading libcrypto in an unsafe way" on macos-11 using Java21 This is using: Java version: 21.0.1, vendor: Eclipse Adoptium, runtime: /Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.1-12.0.LTS/x64/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" Makefile settings: === OS_NAME=Mac OS_ARCH=x86_64 os_arch=Mac-x86_64 === The workflow has been adjusted to allow for this failure -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-368) Allow angle brackets in email-address validation
[ https://issues.apache.org/jira/browse/VALIDATOR-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779802#comment-17779802 ] Sebb commented on VALIDATOR-368: Seems to me that this changes the behaviour of the existing validator. Some users will only want to allow the bare email names without the comments. So this behaviour needs to be optional. > Allow angle brackets in email-address validation > > > Key: VALIDATOR-368 > URL: https://issues.apache.org/jira/browse/VALIDATOR-368 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.4.1 Release >Reporter: Tobias Fink >Priority: Minor > > Email-addresses like "Leo Notenboom " are > validated as invalid by org.apache.commons.validator.routines.EmailValidator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-427) New TrailerInputStream class
[ https://issues.apache.org/jira/browse/IO-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778557#comment-17778557 ] Sebb commented on IO-427: - Why don't you just write the stream to a temporary file, and check the hash on end of stream. If the hash is OK, rename the file, if not, delete it and report an error. In any case, this is such a specialised use case that I don't think it belongs in Commons. > New TrailerInputStream class > > > Key: IO-427 > URL: https://issues.apache.org/jira/browse/IO-427 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Duncan Jones >Priority: Minor > Labels: patch > Attachments: TrailerInputStream.java, TrailerInputStreamTest.java > > > A new input stream for reading data with fixed length trailers/suffixes. This > was briefly discussed on the ML: http://markmail.org/thread/mh4elj7a53mdus2h. > Since I don't often write input streams and haven't contributed to this > project before, I offer this up for review to see if it's a welcome addition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-169) Unable to load native library on Apple Silicon (M1 Mac)
[ https://issues.apache.org/jira/browse/CRYPTO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778316#comment-17778316 ] Sebb commented on CRYPTO-169: - That should be OK. > Unable to load native library on Apple Silicon (M1 Mac) > --- > > Key: CRYPTO-169 > URL: https://issues.apache.org/jira/browse/CRYPTO-169 > Project: Commons Crypto > Issue Type: Bug >Reporter: L. C. Hsieh >Priority: Major > Attachments: image-2023-10-21-17-51-41-260.png, > image-2023-10-21-17-52-02-237.png, image-2023-10-21-17-53-16-898.png, > image-2023-10-21-17-59-13-866.png > > > Recently as trying to upgrade commons-crypto from 1.1.0 to 1.2.0 in Spark > (SPARK-45617), got the following error in one test: > ``` > [info] Cause: java.security.GeneralSecurityException: Native library is not > loaded > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.checkNative(OpenSslCryptoRandom.java:79) > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:65) > > [info] at java.base/java.lang.Class.forName0(Native Method) > > [info] at java.base/java.lang.Class.forName(Class.java:467) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByNameOrNull(ReflectionUtils.java:93) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByName(ReflectionUtils.java:64) > [info] at > org.apache.commons.crypto.random.CryptoRandomFactory.getCryptoRandom(CryptoRandomFactory.java:189) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createInitializationVector(CryptoStreamUtils.scala:138) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createCryptoOutputStream(CryptoStreamUtils.scala:56) > [info] at > org.apache.spark.serializer.SerializerManager.$anonfun$wrapForEncryption$3(SerializerManager.scala:151) > > ``` > I did a quick check. commons-crypto-1.2.0.jar only contain x86_64 Mac native > library, it doesn't provide pre-built native library for Apple Silicon. > But I also checked commons-crypto-1.1.0.jar which Spark uses currently. It > also doesn't provide native library for Apple Silicon. > Since they both don't contain native library for Apple Silicon, why > commons-crypto-1.2.0 doesn't work and what makes the difference between > commons-crypto-1.1.0 and commons-crypto-1.2.0? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-169) Unable to load native library on Apple Silicon (M1 Mac)
[ https://issues.apache.org/jira/browse/CRYPTO-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778297#comment-17778297 ] Sebb commented on CRYPTO-169: - No, it is never acceptable to catch Throwable. Some exceptions should never be caught. > Unable to load native library on Apple Silicon (M1 Mac) > --- > > Key: CRYPTO-169 > URL: https://issues.apache.org/jira/browse/CRYPTO-169 > Project: Commons Crypto > Issue Type: Bug >Reporter: L. C. Hsieh >Priority: Major > Attachments: image-2023-10-21-17-51-41-260.png, > image-2023-10-21-17-52-02-237.png, image-2023-10-21-17-53-16-898.png, > image-2023-10-21-17-59-13-866.png > > > Recently as trying to upgrade commons-crypto from 1.1.0 to 1.2.0 in Spark > (SPARK-45617), got the following error in one test: > ``` > [info] Cause: java.security.GeneralSecurityException: Native library is not > loaded > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.checkNative(OpenSslCryptoRandom.java:79) > [info] at > org.apache.commons.crypto.random.OpenSslCryptoRandom.(OpenSslCryptoRandom.java:65) > > [info] at java.base/java.lang.Class.forName0(Native Method) > > [info] at java.base/java.lang.Class.forName(Class.java:467) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByNameOrNull(ReflectionUtils.java:93) > [info] at > org.apache.commons.crypto.utils.ReflectionUtils.getClassByName(ReflectionUtils.java:64) > [info] at > org.apache.commons.crypto.random.CryptoRandomFactory.getCryptoRandom(CryptoRandomFactory.java:189) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createInitializationVector(CryptoStreamUtils.scala:138) > [info] at > org.apache.spark.security.CryptoStreamUtils$.createCryptoOutputStream(CryptoStreamUtils.scala:56) > [info] at > org.apache.spark.serializer.SerializerManager.$anonfun$wrapForEncryption$3(SerializerManager.scala:151) > > ``` > I did a quick check. commons-crypto-1.2.0.jar only contain x86_64 Mac native > library, it doesn't provide pre-built native library for Apple Silicon. > But I also checked commons-crypto-1.1.0.jar which Spark uses currently. It > also doesn't provide native library for Apple Silicon. > Since they both don't contain native library for Apple Silicon, why > commons-crypto-1.2.0 doesn't work and what makes the difference between > commons-crypto-1.1.0 and commons-crypto-1.2.0? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-129) [build-plugin, release-plugin] Merge codebases
[ https://issues.apache.org/jira/browse/COMMONSSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778098#comment-17778098 ] Sebb commented on COMMONSSITE-129: -- Note that Maven 4 does not support the Ant Mojo Extractor (or other scripted plugins), so all plugins will likely need major rework. > [build-plugin, release-plugin] Merge codebases > -- > > Key: COMMONSSITE-129 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-129 > Project: Apache Commons All > Issue Type: New Feature > Components: Commons Build Plugin, Commons Release Plugin >Reporter: Rob Tompkins >Priority: Major > Labels: GSoC2019 > > These need to both be in the same codebase. The only question remaining is > which codebase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COMMONSSITE-46) Multi-module projects fail when using the "rc" profile in commons-parent
[
https://issues.apache.org/jira/browse/COMMONSSITE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMMONSSITE-46.
-
Resolution: Abandoned
The rc profile no longer exists
> Multi-module projects fail when using the "rc" profile in commons-parent
>
>
> Key: COMMONSSITE-46
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-46
> Project: Apache Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Niall Pemberton
>Priority: Major
> Attachments: commons-parent-pom.patch
>
>
> The "rc" profile doesn't current work with multi-module projects (when the
> project has not been previously installed in your local repo for the current
> version)
> For example running the following command on JCI
> {code}
> mvn -Prc clean install
> {code}
> fails with the following error:
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Missing:
> --
> 1) org.apache.commons:commons-jci-core:jar:1.1-SNAPSHOT
> ...
> {code}
> I found this is caused by trying to run the site plugin in the "rc" profile:
> {code}
>
> maven-site-plugin
>
>
>
> site
>
> package
>
>
>
> {code}
> The intention of the above was so that when the assembly plugin ran to create
> the binary distros then the site would be available to include in the distro.
> AFAIK we are now only shipping javadocs in the binary distros and not any
> component sites. So I plan to remove the site plugin from the "rc" profile
> and add a "javadoc" goal in the javadoc plugin in the "rc" profile. This
> resolves the issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-167) [build-plugin] makes assumptions about workflow names to create badges
[ https://issues.apache.org/jira/browse/COMMONSSITE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778096#comment-17778096 ] Sebb commented on COMMONSSITE-167: -- See also https://issues.apache.org/jira/browse/RNG-38 > [build-plugin] makes assumptions about workflow names to create badges > -- > > Key: COMMONSSITE-167 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-167 > Project: Apache Commons All > Issue Type: Improvement > Components: Commons Build Plugin >Reporter: Sebb >Priority: Major > > The build plugin currently makes assumptions about the GHA workflow names > used to run maven and the code quality analysis. > Most components do comply, but some do not or cannot. > (e.g. Daemon has 2 separate non-Java workflows) > There should be a way to customise the output for components. > Perhaps via property overrides -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-150) Maven Central link/badge for "Commons Numbers" v1.0
[ https://issues.apache.org/jira/browse/COMMONSSITE-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17778095#comment-17778095 ] Sebb commented on COMMONSSITE-150: -- Need more detail if this is to be resolved. The mail link is broken as the 3rd party server no longer exists. Please use lists.a.o instead. > Maven Central link/badge for "Commons Numbers" v1.0 > --- > > Key: COMMONSSITE-150 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-150 > Project: Apache Commons All > Issue Type: Task > Components: Site >Reporter: Gilles Sadowski >Priority: Major > > See [post on the "dev" ML|https://markmail.org/message/njrhacbh3begxclj]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COMMONSSITE-85) https for images
[ https://issues.apache.org/jira/browse/COMMONSSITE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMMONSSITE-85. - Resolution: Fixed Original issue fixed some while ago > https for images > > > Key: COMMONSSITE-85 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-85 > Project: Apache Commons All > Issue Type: Bug > Components: Site >Reporter: Julian Ladisch >Priority: Major > Attachments: https-image.patch > > > https://commons.apache.org/ does not have a green lock icon, but a grey lock > icon with yellow warning sign with the message that the connection is > unsecure. This is caused by two images with http. The patch fixes these > images by replacing http by https to avoid this mixed content warning. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COMMONSSITE-167) [build-plugin] makes assumptions about workflow names to create badges
Sebb created COMMONSSITE-167: Summary: [build-plugin] makes assumptions about workflow names to create badges Key: COMMONSSITE-167 URL: https://issues.apache.org/jira/browse/COMMONSSITE-167 Project: Apache Commons All Issue Type: Improvement Components: Commons Build Plugin Reporter: Sebb The build plugin currently makes assumptions about the GHA workflow names used to run maven and the code quality analysis. Most components do comply, but some do not or cannot. (e.g. Daemon has 2 separate non-Java workflows) There should be a way to customise the output for components. Perhaps via property overrides -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776931#comment-17776931 ] Sebb commented on JEXL-408: --- I am happy with the create() method, as that makes it easy to enable a few specific features. AFAICT to disable just feature A, you need to enable all other features and disable A. There is no way to enable all features currently, so at best you can choose the DEFAULT or SCRIPT set and then add the missing ones. If a new release adds new features, the code will need to be revisited. Changing the default constructor is a separate issue, though if it did enable every feature it would make it easier to disable a few features. An alternate solution would be a createAll() method - maybe create() should be renamed createNone() > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776928#comment-17776928 ] Sebb commented on JEXL-410: --- It's not about convenience, it's about not honouring the Javadoc. As to breaking scripts: The LEXICAL flags and CONST_CAPTURE appear to be restrictive flags, so could cause failures. AFAICT REGISTER and FAT_ARROW are permissive, so surely cannot cause script failures if enabled? Indeed if the related syntax was available before the flags were added, then omitting them from the default can cause failures. It looks like the default flag set was updated in the past when new features were added - why was this not done for all new flags? > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-410) JexlFeatures: ctor does not enable all features
[ https://issues.apache.org/jira/browse/JEXL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776765#comment-17776765 ] Sebb commented on JEXL-410: --- I think that is the wrong fix. I think the original Javadoc should be honoured; that helps with JEXL-408 as well. > JexlFeatures: ctor does not enable all features > --- > > Key: JEXL-410 > URL: https://issues.apache.org/jira/browse/JEXL-410 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The ctor Javadoc says it "Creates an all-features-enabled instance." > However, that is not the case, as several flags are not included: > REGISTER > LEXICAL > LEXICAL_SHADE > FAT_ARROW > CONST_CAPTURE > (RESERVED is also omitted, but it is not a feature flag - it only indicates > reservedNames is non-empty) > If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-408) Using JexlFeatures is tedious
[ https://issues.apache.org/jira/browse/JEXL-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776759#comment-17776759 ] Sebb commented on JEXL-408: --- It is also tedious to create an instance that disables a single feature. Originally this was possible using the default constructor (as promised by its Javadoc), but the default was not always updated when additional features were added. I think it might be better to honour the original Javadoc. This would solve this issue. > Using JexlFeatures is tedious > - > > Key: JEXL-408 > URL: https://issues.apache.org/jira/browse/JEXL-408 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Sebb >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3.1 > > > The JexlFeatures class is not very easy to configure if one wants to disable > all but one or two features. This is because the only constructor includes > many features by default. These all have to be disabled individually. > It would be useful to have a constructor that disabled all the features; > these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-410) JexlFeatures: ctor does not enable all features
Sebb created JEXL-410: - Summary: JexlFeatures: ctor does not enable all features Key: JEXL-410 URL: https://issues.apache.org/jira/browse/JEXL-410 Project: Commons JEXL Issue Type: Bug Reporter: Sebb The ctor Javadoc says it "Creates an all-features-enabled instance." However, that is not the case, as several flags are not included: REGISTER LEXICAL LEXICAL_SHADE FAT_ARROW CONST_CAPTURE (RESERVED is also omitted, but it is not a feature flag - it only indicates reservedNames is non-empty) If these are intentional omissions, they should be documented as such. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-409) Disable LEXICAL should disable LEXICAL_SHADE
Sebb created JEXL-409: - Summary: Disable LEXICAL should disable LEXICAL_SHADE Key: JEXL-409 URL: https://issues.apache.org/jira/browse/JEXL-409 Project: Commons JEXL Issue Type: Bug Reporter: Sebb The code to enable LEXICAL_SHADE automatically enables LEXICAL. However the code to disable LEXICAL does not disable LEXICAL_SHADE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JEXL-408) Using JexlFeatures is tedious
Sebb created JEXL-408: - Summary: Using JexlFeatures is tedious Key: JEXL-408 URL: https://issues.apache.org/jira/browse/JEXL-408 Project: Commons JEXL Issue Type: Improvement Reporter: Sebb The JexlFeatures class is not very easy to configure if one wants to disable all but one or two features. This is because the only constructor includes many features by default. These all have to be disabled individually. It would be useful to have a constructor that disabled all the features; these could then be enabled individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-414) IOUtils.writeLines is not correct with a charset with BOM
[ https://issues.apache.org/jira/browse/IO-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772886#comment-17772886 ] Sebb commented on IO-414: - e.g. https://github.com/apache/commons-io/actions/runs/6441844619/job/17492833682 Looks to me like this is a symptom of an EOL issue. > IOUtils.writeLines is not correct with a charset with BOM > - > > Key: IO-414 > URL: https://issues.apache.org/jira/browse/IO-414 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers, Utilities >Affects Versions: 2.4, 2.5 >Reporter: Florent Brosse >Priority: Major > Fix For: 2.14.1 > > > When a charset has a BOM (like UTF-16), the method IOUtils.writeLines put 2 > BOM on each line. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IO-815) XmlStreamReader encoding match RE is too strict
[ https://issues.apache.org/jira/browse/IO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-815. - Resolution: Fixed > XmlStreamReader encoding match RE is too strict > --- > > Key: IO-815 > URL: https://issues.apache.org/jira/browse/IO-815 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.14.0 >Reporter: Sebb >Priority: Major > Fix For: 2.14.1 > > > The RE for matching encoding strings was tightened up in 2.14.0. > Whilst the RE still matches canonical encoding names, it does not match some > aliases. > For example: '437', 'ISO_8859-1:1987' and 'ebcdic-de-273+euro' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-815) XmlStreamReader encoding match RE is too strict
[ https://issues.apache.org/jira/browse/IO-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771647#comment-17771647 ] Sebb commented on IO-815: - Fixed in https://github.com/apache/commons-io/commit/841b5fafe13683389d078ec7a7adf736c05e038e > XmlStreamReader encoding match RE is too strict > --- > > Key: IO-815 > URL: https://issues.apache.org/jira/browse/IO-815 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.14.0 >Reporter: Sebb >Priority: Major > Fix For: 2.14.1 > > > The RE for matching encoding strings was tightened up in 2.14.0. > Whilst the RE still matches canonical encoding names, it does not match some > aliases. > For example: '437', 'ISO_8859-1:1987' and 'ebcdic-de-273+euro' -- This message was sent by Atlassian Jira (v8.20.10#820010)
