[jira] [Comment Edited] (FINERACT-2084) Broken download link
[
https://issues.apache.org/jira/browse/FINERACT-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847208#comment-17847208
]
Sebb edited comment on FINERACT-2084 at 5/17/24 8:52 AM:
-
It looks like '\{version\}' should be replaced by '1.9.0' to trigger the
correct redirect.
was (Author: s...@apache.org):
It looks like '{version}' should be replaced by '1.9.0' to trigger the correct
redirect.
> Broken download link
>
>
> Key: FINERACT-2084
> URL: https://issues.apache.org/jira/browse/FINERACT-2084
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Sebb
>Priority: Blocker
>
> https://github.com/apache/fineract-site/blob/e30d3d62d5aa1a580a879ece0aca92c87260ecd5/index.html#L185
> does not link to the correct file, and is not a valid URI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-2084) Broken download link
[ https://issues.apache.org/jira/browse/FINERACT-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated FINERACT-2084: --- Priority: Blocker (was: Major) > Broken download link > > > Key: FINERACT-2084 > URL: https://issues.apache.org/jira/browse/FINERACT-2084 > Project: Apache Fineract > Issue Type: Bug >Reporter: Sebb >Priority: Blocker > > https://github.com/apache/fineract-site/blob/e30d3d62d5aa1a580a879ece0aca92c87260ecd5/index.html#L185 > does not link to the correct file, and is not a valid URI -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2084) Broken download link
[
https://issues.apache.org/jira/browse/FINERACT-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847208#comment-17847208
]
Sebb commented on FINERACT-2084:
It looks like '{version}' should be replaced by '1.9.0' to trigger the correct
redirect.
> Broken download link
>
>
> Key: FINERACT-2084
> URL: https://issues.apache.org/jira/browse/FINERACT-2084
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Sebb
>Priority: Blocker
>
> https://github.com/apache/fineract-site/blob/e30d3d62d5aa1a580a879ece0aca92c87260ecd5/index.html#L185
> does not link to the correct file, and is not a valid URI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-2084) Broken download link
Sebb created FINERACT-2084: -- Summary: Broken download link Key: FINERACT-2084 URL: https://issues.apache.org/jira/browse/FINERACT-2084 Project: Apache Fineract Issue Type: Bug Reporter: Sebb https://github.com/apache/fineract-site/blob/e30d3d62d5aa1a580a879ece0aca92c87260ecd5/index.html#L185 does not link to the correct file, and is not a valid URI -- 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=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=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=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=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] (WHIMSY-414) Roll call tool to simplify PMC roll calls
[ https://issues.apache.org/jira/browse/WHIMSY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839427#comment-17839427 ] Sebb commented on WHIMSY-414: - Note: not all PMCs currently have private /pmc/ entries, but it does not take long to set them up. AFAICT the directory can be created by any ASF member. The permission database (pit-authorization-template) would need an Infra OK. > Roll call tool to simplify PMC roll calls > - > > Key: WHIMSY-414 > URL: https://issues.apache.org/jira/browse/WHIMSY-414 > Project: Whimsy > Issue Type: New Feature > Components: Roster >Reporter: Craig L Russell >Priority: Major > > During review of project board reports, directors encounter projects that > seem to be in decline. In order to determine whether the PMC is healthy > enough for proper oversight, the board requests a roll call and assigns an > action item to a director. > To start the roll call, a director goes to the Whimsy roster page for the > PMC, and clicks "send roll call". Director writes out an explanation of any > specific board concerns, which is then sent out along with a boilerplate > explanation of the roll call process, along with a "reply by this date to > roll call here" link. > PMC members click the link (which auth's them), fill out short form, and > click submit. The board really needs to know the "how engaged are you" > detail, and we could also have an extra comments field where PMC members > might add extra data. > Every submission results in a commit (by Whimsy) into a private repository > (visible to Members and Officers) as well as an email to board@ and > private@. The repository should be easy to search by name by > logged-in users, e.g. > [https://svn.apache.org/repos/private/pmc//|https://svn.apache.org/repos/private/pmc/]roll-call/2024-04-01/.json. > > > PMC members should be allowed to save their responses in a specific roll call > request directory > PMC members should be allowed to review/read responses from their peers in > any of their svn project roll call directories > Members and Officers should be allowed to review/read responses from any of > the repositories > Other access should be disallowed > It's easy to track responses by Apache ID, and by date of response, as well > as have a simple read-only dashboard showing the outcome of each roll call, > assuming the right privileges. > PMC members could also see each others' responses in email. > Working example (you will be auth'd by your Apache ID): > [https://whimsy.apache.org/officers/surveys?survey=test-rollcall.json] > In this POC, commits go to foundation/officers/surveys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WHIMSY-414) Roll call tool to simplify PMC roll calls
[ https://issues.apache.org/jira/browse/WHIMSY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839364#comment-17839364 ] Sebb commented on WHIMSY-414: - The private PMC directory entries at https://svn.apache.org/repos/private/pmc/ have suitable authentication requirements: RW for PMC members and ASF members, no access otherwise. These would be suitable for the survey response data and questionnaires. > Roll call tool to simplify PMC roll calls > - > > Key: WHIMSY-414 > URL: https://issues.apache.org/jira/browse/WHIMSY-414 > Project: Whimsy > Issue Type: New Feature > Components: Roster >Reporter: Craig L Russell >Priority: Major > > During review of project board reports, directors encounter projects that > seem to be in decline. In order to determine whether the PMC is healthy > enough for proper oversight, the board requests a roll call and assigns an > action item to a director. > To start the roll call, a director goes to the Whimsy roster page for the > PMC, and clicks "send roll call". Director writes out an explanation of any > specific board concerns, which is then sent out along with a boilerplate > explanation of the roll call process, along with a "reply by this date to > roll call here" link. > PMC members click the link (which auth's them), fill out short form, and > click submit. The board really needs to know the "how engaged are you" > detail, and we could also have an extra comments field where PMC members > might add extra data. > Every submission results in a commit (by Whimsy) into a private repository > (visible to Members and Officers) as well as an email to board@ and > private@. The repository should be easy to search by name, e.g. > foundation/officers/roll-calls//roll-call-2024-04-01/.json. > > > PMC members should be allowed to save their responses in a specific roll call > request directory > PMC members should be allowed to review/read responses from their peers in > any of their svn project roll call directories > Members and Officers should be allowed to review/read responses from any of > the repositories > Other access should be disallowed > It's easy to track responses by Apache ID, and by date of response, as well > as have a simple read-only dashboard showing the outcome of each roll call, > assuming the right privileges. > PMC members could also see each others responses in email. > Working example (you will be auth'd by your Apache ID): > [https://whimsy.apache.org/officers/surveys?survey=test-rollcall.json] > In this POC, commits go to foundation/officers/surveys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WHIMSY-414) Roll call tool to simplify PMC roll calls
[ https://issues.apache.org/jira/browse/WHIMSY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839228#comment-17839228 ] Sebb commented on WHIMSY-414: - Some thought needs to be given to the karma required to read and write the survey data. For a PMC roll call, it is obviously vital that all current PMC members can provide responses to their own surveys, but what access should PMC members have to surveys for other PMCs (if they are not an ASF member)? One solution to this might be to store the survey data under the relevant SVN /private/pmc/ directory tree. Should non-ASF members be able to see the survey questions for PMCs other than their own? > Roll call tool to simplify PMC roll calls > - > > Key: WHIMSY-414 > URL: https://issues.apache.org/jira/browse/WHIMSY-414 > Project: Whimsy > Issue Type: New Feature > Components: Roster >Reporter: Craig L Russell >Priority: Major > > During review of project board reports, directors encounter projects that > seem to be in decline. In order to determine whether the PMC is healthy > enough for proper oversight, the board requests a roll call and assigns an > action item to a director. > To start the roll call, a director goes to the Whimsy roster page for the > PMC, and clicks "send roll call". Director writes out an explanation of any > specific board concerns, which is then sent out along with a boilerplate > explanation of the roll call process, along with a "reply by this date to > roll call here" link. > PMC members click the link (which auth's them), fill out short form, and > click submit. The board really needs to know the "how engaged are you" > detail, and we could also have an extra comments field where PMC members > might add extra data. > Every submission results in a commit (by Whimsy) into a private repository > (visible to Members and Officers) as well as an email to board@ and > private@. The repository should be easy to search by name, e.g. > foundation/officers/roll-calls//roll-call-2024-04-01/.json. > > It's easy to track responses by Apache ID, and by date of response, as well > as have a simple read-only dashboard showing the outcome of each roll call, > assuming the right privileges. > PMC members could also see each others responses in email. > Working example (you will be auth'd by your Apache ID): > [https://whimsy.apache.org/officers/surveys?survey=test-rollcall.json] > In this POC, commits go to foundation/officers/surveys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMDEV-544) Improve comdev website navigation to GSoC mentor resources
[
https://issues.apache.org/jira/browse/COMDEV-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838688#comment-17838688
]
Sebb commented on COMDEV-544:
-
Note that there is a Mentor link under GSoC menu item on most pages
> Improve comdev website navigation to GSoC mentor resources
> --
>
> Key: COMDEV-544
> URL: https://issues.apache.org/jira/browse/COMDEV-544
> Project: Community Development
> Issue Type: Task
> Components: Website
>Reporter: Lewis John McGibbney
>Priority: Minor
>
> h1. Purpose
> Improve comdev website navigation to Google Summer of Code (GSoC) mentor
> resources.
> h1. Context
> Having been ‘away’ for a few years, this year I decided to make an attempt to
> re-engage with the GSoC program.
> I quickly realized that I was totally out of touch having absolutely no idea
> where the mentor community conversations were happening (they happen on
> ment...@community.apache.org) and being hopelessly unable to locate GSoC
> mentoring documentation via the comdev website.
> Thankfully [~sanyam] [pointed me at the
> documentation|[https://lists.apache.org/thread/dqmrwzjogl3sdb2v8s36v8mxf5o1yqsj]]
> and I was able to get back up to speed. Thank you Sanyam :)
> h1. Challenges
> Looking at [https://community.apache.org/gsoc/], as of writing, although
> loads of content exists for students (which is great) no navigation exists to
> mentor resources.
> In my case, this meant that I couldn’t find and entirely missed the excellent
> content available at [https://community.apache.org/mentoring]/.
> h1. Proposal
> I think that a “{*}Mentors: read this{*}” Section should be added to
> [https://community.apache.org/gsoc/] which simply hyperlinks to the relevant
> content from above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
[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=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] (INCUBATOR-283) Please delete tag v2.0.0 in incubator-horaedb
[ https://issues.apache.org/jira/browse/INCUBATOR-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828266#comment-17828266 ] Sebb commented on INCUBATOR-283: There is some git hook code that appears to protect certain tags by default. However, I mis-remembered and such tags are prefixed rel/, not releases/. So the project should be able to drop the incorrect tag. It's not clear if the asf.yaml file can change the default protections (if any) or merely add to them. I've raised https://issues.apache.org/jira/browse/INFRA-25622 about the asf.yaml documentation. > Please delete tag v2.0.0 in incubator-horaedb > - > > Key: INCUBATOR-283 > URL: https://issues.apache.org/jira/browse/INCUBATOR-283 > Project: Incubator > Issue Type: Task >Reporter: Chunshao Ren >Priority: Minor > > Please delete the tag v2.0.0, as it was created by mistake earlier. The > version 2.0.0 is currently undergoing a vote. > https://github.com/apache/incubator-horaedb/releases/tag/v2.0.0 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-283) Please delete tag v2.0.0 in incubator-horaedb
[ https://issues.apache.org/jira/browse/INCUBATOR-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828246#comment-17828246 ] Sebb commented on INCUBATOR-283: release tags are supposed to be immutable, and cannot normally be deleted. I think you will need to involve Infra to get this corrected. > Please delete tag v2.0.0 in incubator-horaedb > - > > Key: INCUBATOR-283 > URL: https://issues.apache.org/jira/browse/INCUBATOR-283 > Project: Incubator > Issue Type: Task >Reporter: Chunshao Ren >Priority: Minor > > Please delete the tag v2.0.0, as it was created by mistake earlier. The > version 2.0.0 is currently undergoing a vote. > https://github.com/apache/incubator-horaedb/releases/tag/v2.0.0 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[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=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] (WHIMSY-413) Download checker does not recognize sub-projects
[ https://issues.apache.org/jira/browse/WHIMSY-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved WHIMSY-413. - Resolution: Not A Bug Please see my reply on the dev@mailing list > Download checker does not recognize sub-projects > > > Key: WHIMSY-413 > URL: https://issues.apache.org/jira/browse/WHIMSY-413 > Project: Whimsy > Issue Type: Bug > Components: General >Reporter: Craig L Russell >Priority: Minor > > https://whimsy.apache.org/members/download_check.cgi > > fails page db.apache.org/jdo/download.html because it doesn't recognize db as > an umbrella project that currently has two sub-projects: jdo and derby, which > have their respective web sites and download pages. > > https://db.apache.org/derby/ > https://db.apache.org/jdo/ > > and their download pages > > https://db.apache.org/derby/derby_downloads.html > https://db.apache.org/jdo/downloads.html > > This is a special case -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (STEVE-81) UI bug has been fixed
Sebb created STEVE-81: - Summary: UI bug has been fixed Key: STEVE-81 URL: https://issues.apache.org/jira/browse/STEVE-81 Project: Steve Issue Type: Bug Reporter: Sebb The text "Note: The have-you-voted UI mechanism is currently suffering from a bug, and may not correctly highlight all the issues you have already voted on. Your votes *ARE* saved, this is a display bug." is no longer appropriate -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (STEVE-80) Wrong use of strip() method
Sebb created STEVE-80: - Summary: Wrong use of strip() method Key: STEVE-80 URL: https://issues.apache.org/jira/browse/STEVE-80 Project: Steve Issue Type: Bug Reporter: Sebb https://github.com/apache/steve/blob/d94e7169acdc892d798e001c3f2c2d314d4c35b3/pysteve/lib/backends/files.py#L140 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (STEVE-79) Bulk vote page does not show UI bug disclaimer
Sebb created STEVE-79: - Summary: Bulk vote page does not show UI bug disclaimer Key: STEVE-79 URL: https://issues.apache.org/jira/browse/STEVE-79 Project: Steve Issue Type: Bug Reporter: Sebb The main page has a disclaimer: "Note: The have-you-voted UI mechanism is currently suffering from a bug, and may not correctly highlight all the issues you have already voted on. Your votes *ARE* saved, this is a display bug." The bulk vote page suffers from the same bug, but does not have the disclaimer. If the UI bug cannot be fixed, at least the disclaimer could be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (STEVE-78) Multiple broken links on website
Sebb created STEVE-78: - Summary: Multiple broken links on website Key: STEVE-78 URL: https://issues.apache.org/jira/browse/STEVE-78 Project: Steve Issue Type: Bug Reporter: Sebb As the subject says. Most of the menu links are broken. On the community support page, the archive links are broken, as are the links under Contributing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WHIMSY-412) Proxy volunteers are not all selectable in the proxy designation form
[
https://issues.apache.org/jira/browse/WHIMSY-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved WHIMSY-412.
-
Resolution: Information Provided
Greg has assigned a proxy for himself; as such, he cannot be a proxy.
> Proxy volunteers are not all selectable in the proxy designation form
> -
>
> Key: WHIMSY-412
> URL: https://issues.apache.org/jira/browse/WHIMSY-412
> Project: Whimsy
> Issue Type: Bug
>Reporter: C. Michael Pilato
>Priority: Major
> Attachments: Screenshot from 2024-02-29 15-38-45.png, Screenshot from
> 2024-02-29 15-39-42.png
>
>
> At the time of writing, there are three members listed as having volunteered
> as proxies at [https://whimsy.apache.org/members/proxy]. Unfortunately, one
> of those ({{{}Greg Stein (gstein){}}}) is not presented in the drop-down
> selector as a viable option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (WHIMSY-411) False negatives for sponsors
[ https://issues.apache.org/jira/browse/WHIMSY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved WHIMSY-411. - Resolution: Invalid https://www.apache.org/foundation/marks/pmcs#navigation says "Sponsors", "Thanks" or "Thanks to our Sponsors" should link to: www.apache.org/foundation/thanks.html > False negatives for sponsors > - > > Key: WHIMSY-411 > URL: https://issues.apache.org/jira/browse/WHIMSY-411 > Project: Whimsy > Issue Type: Bug > Components: Website >Reporter: Craig L Russell >Priority: Minor > > The website checker fails pages that do not link to the thanks page. > However, links to the sponsors page should also be passed. For example, > [https://pekko.apache.org|https://pekko.apache.org/] fails the check but has > "Thanks" text that links to [https://www.apache.org/foundation/sponsors] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WHIMSY-408) Update meetings.cgi to derive meeting dates automatically
[ https://issues.apache.org/jira/browse/WHIMSY-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818112#comment-17818112 ] Sebb commented on WHIMSY-408: - Well spotted, and thanks for the patch. Note that it was reversed, but as it is quite a simple change I did it manually. > Update meetings.cgi to derive meeting dates automatically > - > > Key: WHIMSY-408 > URL: https://issues.apache.org/jira/browse/WHIMSY-408 > Project: Whimsy > Issue Type: Task >Reporter: Sebb >Priority: Major > Attachments: weekday.patch > > > The meeting.cgi file currently needs to be manually updated each year, see > the code near > https://github.com/apache/whimsy/blob/master/www/members/meeting.cgi#L157 > It might perhaps make sense to automate this by reading from > https://svn.apache.org/repos/private/foundation/Meetings/MMDD/README.txt > or the script that generates it > https://svn.apache.org/repos/private/foundation/Meetings/create-meeting.rb > Better yet might be for create-meeting.rb to generate a data file in a fixed > location that can be used by other scripts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (ATTIC-217) Move Giraph to the Attic
[ https://issues.apache.org/jira/browse/ATTIC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817621#comment-17817621 ] Sebb edited comment on ATTIC-217 at 2/15/24 9:32 AM: - I think the issue has not been resolved because not all of the tasks have been completed. (so it should probably not have been added to the board report). Discussions about Attic procedures should take place on an Attic mailing list. For sensitive items that is the private list, but otherwise use general@attic Please don't hijack a Jira issue for unrelated topics. Either use separate emails, or raise new issues. That way they can be dealt with properly, without affecting the original issue. Thanks. was (Author: s...@apache.org): I think the issue has not been resolved because not all of the tasks have been completed. (so it should probably not have been added to the board report). Discussions about Attic procedures should take place on an Attic mailing list. For sensitive items that is the private list, but otherwise use general@attic > Move Giraph to the Attic > > > Key: ATTIC-217 > URL: https://issues.apache.org/jira/browse/ATTIC-217 > Project: Attic > Issue Type: Task >Reporter: Herve Boutemy >Priority: Major > > # Confirm Board Resolution (/) > # Inform > [users|https://lists.apache.org/thread/h9kfjho2ss8pb103q54dchltntzktw53] of > the move to the Attic (/) > # Create project page on Attic site: > [http://attic.apache.org/projects/giraph|http://attic.apache.org/projects/giraph.html] > (/) > # Ensure [original project site|http://giraph.apache.org/] pages carry the > Attic banner (/) > # Update the project DOAP file (if any) or copy to > [projects-override|https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects-override/]: > (/) > # Announce on [announce at > apache.org|http://mail-archives.apache.org/mod_mbox/www-announce/] (!) > See [http://attic.apache.org/process.html#howto] for detailed instructions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ATTIC-217) Move Giraph to the Attic
[ https://issues.apache.org/jira/browse/ATTIC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817621#comment-17817621 ] Sebb commented on ATTIC-217: I think the issue has not been resolved because not all of the tasks have been completed. (so it should probably not have been added to the board report). Discussions about Attic procedures should take place on an Attic mailing list. For sensitive items that is the private list, but otherwise use general@attic > Move Giraph to the Attic > > > Key: ATTIC-217 > URL: https://issues.apache.org/jira/browse/ATTIC-217 > Project: Attic > Issue Type: Task >Reporter: Herve Boutemy >Priority: Major > > # Confirm Board Resolution (/) > # Inform > [users|https://lists.apache.org/thread/h9kfjho2ss8pb103q54dchltntzktw53] of > the move to the Attic (/) > # Create project page on Attic site: > [http://attic.apache.org/projects/giraph|http://attic.apache.org/projects/giraph.html] > (/) > # Ensure [original project site|http://giraph.apache.org/] pages carry the > Attic banner (/) > # Update the project DOAP file (if any) or copy to > [projects-override|https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects-override/]: > (/) > # Announce on [announce at > apache.org|http://mail-archives.apache.org/mod_mbox/www-announce/] (!) > See [http://attic.apache.org/process.html#howto] for detailed instructions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WHIMSY-409) members/proxy.cgi allows for submission of non-selected proxy
[ https://issues.apache.org/jira/browse/WHIMSY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved WHIMSY-409. - Resolution: Fixed Updated code to reject invalid/missing proxy entries > members/proxy.cgi allows for submission of non-selected proxy > - > > Key: WHIMSY-409 > URL: https://issues.apache.org/jira/browse/WHIMSY-409 > Project: Whimsy > Issue Type: Bug >Reporter: Sander Striker >Priority: Major > > The proxy.cgi script allows for submission of an empty proxy. This results > in the tool no longer working as the proxies file becomes invalid when parsed. > Potential workaround is to preselect the secretary as the default: > https://github.com/apache/whimsy/pull/197 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WHIMSY-410) members/inactive.cgi does not show the 2023 meeting
[ https://issues.apache.org/jira/browse/WHIMSY-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved WHIMSY-410. - Resolution: Information Provided > members/inactive.cgi does not show the 2023 meeting > --- > > Key: WHIMSY-410 > URL: https://issues.apache.org/jira/browse/WHIMSY-410 > Project: Whimsy > Issue Type: Bug >Reporter: Sander Striker >Priority: Major > > Visiting [https://whimsy.apache.org/members/inactive] I don't see 2023 in the > list. The text on the page suggest we are missed a step in updating our > attendance records after the 2023 meeting? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WHIMSY-410) members/inactive.cgi does not show the 2023 meeting
[ https://issues.apache.org/jira/browse/WHIMSY-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815664#comment-17815664 ] Sebb commented on WHIMSY-410: - There is no attend file under Meetings/20230309; possibly other files are missing. Fixing this is out of scope for Whimsy > members/inactive.cgi does not show the 2023 meeting > --- > > Key: WHIMSY-410 > URL: https://issues.apache.org/jira/browse/WHIMSY-410 > Project: Whimsy > Issue Type: Bug >Reporter: Sander Striker >Priority: Major > > Visiting [https://whimsy.apache.org/members/inactive] I don't see 2023 in the > list. The text on the page suggest we are missed a step in updating our > attendance records after the 2023 meeting? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (WHIMSY-408) Update meetings.cgi to derive meeting dates automatically
Sebb created WHIMSY-408: --- Summary: Update meetings.cgi to derive meeting dates automatically Key: WHIMSY-408 URL: https://issues.apache.org/jira/browse/WHIMSY-408 Project: Whimsy Issue Type: Task Reporter: Sebb The meeting.cgi file currently needs to be manually updated each year, see the code near https://github.com/apache/whimsy/blob/master/www/members/meeting.cgi#L157 It might perhaps make sense to automate this by reading from https://svn.apache.org/repos/private/foundation/Meetings/MMDD/README.txt or the script that generates it https://svn.apache.org/repos/private/foundation/Meetings/create-meeting.rb Better yet might be for create-meeting.rb to generate a data file in a fixed location that can be used by other scripts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WHIMSY-407) SVN authentication prevents mailinglist subscription
[
https://issues.apache.org/jira/browse/WHIMSY-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813359#comment-17813359
]
Sebb commented on WHIMSY-407:
-
Please try again; there was a config error which has hopefully been corrected.
> SVN authentication prevents mailinglist subscription
>
>
> Key: WHIMSY-407
> URL: https://issues.apache.org/jira/browse/WHIMSY-407
> Project: Whimsy
> Issue Type: Bug
> Components: Mail
>Reporter: Arnout Engelen
>Priority: Major
>
> When I tried to subscribe myself (address
> [enge...@apache.org|mailto:enge...@apache.org]) to the mailinglist
> priv...@pekko.apache.org, I got:
>
> Submitting subscribe request: \{ "version": 3, "availid": "engelen", "addr":
> "enge...@apache.org", "listkey": "priv...@pekko.apache.org", "member_p":
> false, "chair_p": false }
> svn checkout --non-interactive --
> https://svn.apache.org/repos/infra/infrastructure/trunk/subreq/
> /tmp/d20240201-1070894-1xv3tbb
> svn: E170013: Unable to connect to a repository at URL
> 'https://svn.apache.org/repos/infra/infrastructure/trunk/subreq'
> svn: E215004: No more credentials or we tried too many times.
> Authentication failed
> svn commit --non-interactive --message priv...@pekko.apache.org\ +\=\ engelen
> -- engelen-pekko-private.json
> svn: E155007: '/tmp/d20240201-1070894-1xv3tbb/engelen-pekko-private.json' is
> not a working copy
>
> Trying again did not appear to help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (INCUBATOR-199) Extend podlings.xml to include old names and TLP parent
[ https://issues.apache.org/jira/browse/INCUBATOR-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reassigned INCUBATOR-199: -- Assignee: (was: Sebb) > Extend podlings.xml to include old names and TLP parent > --- > > Key: INCUBATOR-199 > URL: https://issues.apache.org/jira/browse/INCUBATOR-199 > Project: Incubator > Issue Type: New Feature >Reporter: Sebb >Priority: Major > > Podling names change fairly often. > It would be useful to be able to list old names in the podlings file. > At present this info is only in the free-form text. > Also where a podling graduates as a project of a PMC, it would be useful to > be able to document the PMC. At present this would have to be extracted from > the url field (or the text) > AFAIK additional attributes do not cause problems for existing parsing > routines. However the DTD will have to be extended to allow for the new > entries. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (HADOOP-13147) Constructors must not call overrideable methods
[ https://issues.apache.org/jira/browse/HADOOP-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803158#comment-17803158 ] Sebb commented on HADOOP-13147: --- What is the point of saying "*please move back if it is a blocker.* " if you don't intend to allow it? > Constructors must not call overrideable methods > --- > > Key: HADOOP-13147 > URL: https://issues.apache.org/jira/browse/HADOOP-13147 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 2.0.6-alpha > Environment: > http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/PureJavaCrc32C.java >Reporter: Sebb >Priority: Blocker > Labels: pull-request-available > > Constructors must not call overrideable methods. > An object is not guaranteed fully constructed until the constructor exits, so > the subclass override may not see the fully created parent object. > This applies to: > PureJavaCrc32 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13147) Constructors must not call overrideable methods
[ https://issues.apache.org/jira/browse/HADOOP-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated HADOOP-13147: -- Target Version/s: 3.4.0 (was: 3.5.0) > Constructors must not call overrideable methods > --- > > Key: HADOOP-13147 > URL: https://issues.apache.org/jira/browse/HADOOP-13147 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 2.0.6-alpha > Environment: > http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/PureJavaCrc32C.java >Reporter: Sebb >Priority: Blocker > Labels: pull-request-available > > Constructors must not call overrideable methods. > An object is not guaranteed fully constructed until the constructor exits, so > the subclass override may not see the fully created parent object. > This applies to: > PureJavaCrc32 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13147) Constructors must not call overrideable methods
[ https://issues.apache.org/jira/browse/HADOOP-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated HADOOP-13147: -- Priority: Blocker (was: Major) > Constructors must not call overrideable methods > --- > > Key: HADOOP-13147 > URL: https://issues.apache.org/jira/browse/HADOOP-13147 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 2.0.6-alpha > Environment: > http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/PureJavaCrc32C.java >Reporter: Sebb >Priority: Blocker > Labels: pull-request-available > > Constructors must not call overrideable methods. > An object is not guaranteed fully constructed until the constructor exits, so > the subclass override may not see the fully created parent object. > This applies to: > PureJavaCrc32 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-13147) Constructors must not call overrideable methods
[ https://issues.apache.org/jira/browse/HADOOP-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated HADOOP-13147: -- Target Version/s: 3.4.0 (was: 3.5.0) > Constructors must not call overrideable methods > --- > > Key: HADOOP-13147 > URL: https://issues.apache.org/jira/browse/HADOOP-13147 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 2.0.6-alpha > Environment: > http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/PureJavaCrc32C.java >Reporter: Sebb >Priority: Major > Labels: pull-request-available > > Constructors must not call overrideable methods. > An object is not guaranteed fully constructed until the constructor exits, so > the subclass override may not see the fully created parent object. > This applies to: > PureJavaCrc32 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Created] (HIVE-27971) Sentence does not make sense
Sebb created HIVE-27971: --- Summary: Sentence does not make sense Key: HIVE-27971 URL: https://issues.apache.org/jira/browse/HIVE-27971 Project: Hive Issue Type: Bug Components: Documentation Reporter: Sebb The main page https://hive.apache.org/ has the sentence: "Hive provides full acid support for ORC tables out and insert only support to all other formats." This does not make sense to me. Also, I think 'acid' should be 'ACID'. What does ORC stand for? It would help to link acronyms such as ACID, ORC to a glossary (or provide suitable hover text). -- 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:#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:#7f0055}return{color}{color:#00}
[jira] [Created] (COMDEV-539) chi report disagrees with mail stats
Sebb created COMDEV-539: --- Summary: chi report disagrees with mail stats Key: COMDEV-539 URL: https://issues.apache.org/jira/browse/COMDEV-539 Project: Community Development Issue Type: Bug Components: Reporter Tool Reporter: Sebb The chi analysis disagrees with the mailing list stats for several projects. e.g. chi score explanation says "No email sent to ANY ML in the past quarter" but the mailing list trends show that there were emails in the last quarter. This occurs for several projects. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[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] (SUREFIRE-2218) Add support for fetching test classes from a jar
[
https://issues.apache.org/jira/browse/SUREFIRE-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792014#comment-17792014
]
Sebb commented on SUREFIRE-2218:
That would be fine as a name.
BTW, the documentation is a bit ambiguous as to what 'test classpath' means.
AFAICT it is only used for the classes under test, but the description for
{{testClassesDirectory}} suggests otherwise.
> Add support for fetching test classes from a jar
>
>
> Key: SUREFIRE-2218
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2218
> Project: Maven Surefire
> Issue Type: New Feature
>Reporter: Sebb
>Priority: Minor
>
> Surefire provides a way to test classes that are in a jar.
> The parameter additionalClasspathElements can used to specify the jar (and
> the
> classesDirectory parameter can be redirected to prevent access to the default
> classes)
>
> It would be useful to be able to do the same for the test classes, i.e.
> provide a parameter that can be used to update the classpath used to find
> tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2218) Add support for fetching test classes from a jar
Sebb created SUREFIRE-2218: -- Summary: Add support for fetching test classes from a jar Key: SUREFIRE-2218 URL: https://issues.apache.org/jira/browse/SUREFIRE-2218 Project: Maven Surefire Issue Type: New Feature Reporter: Sebb Surefire provides a way to test classes that are in a jar. The parameter additionalClasspathElements can used to specify the jar (and the classesDirectory parameter can be redirected to prevent access to the default classes) It would be useful to be able to do the same for the test classes, i.e. provide a parameter that can be used to update the classpath used to find tests -- 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=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=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] [Commented] (INCUBATOR-279) Tuweni retired, but cleanup is incomplete
[ https://issues.apache.org/jira/browse/INCUBATOR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790241#comment-17790241 ] Sebb commented on INCUBATOR-279: The index page was updated to point to the Attic, but that was wrong, as the Attic only deals with PMCs (and so the link is broken). > Tuweni retired, but cleanup is incomplete > - > > Key: INCUBATOR-279 > URL: https://issues.apache.org/jira/browse/INCUBATOR-279 > Project: Incubator > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The LDAP project list still needs to be removed. > Also podlings.xml and tuweni.xml need to be updated, and the website site > redirect needs to be set up. > Maybe the retirement instructions need to be reviewed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-279) Tuweni retired, but cleanup is incomplete
[ https://issues.apache.org/jira/browse/INCUBATOR-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790240#comment-17790240 ] Sebb commented on INCUBATOR-279: Still not complete. The website needs to be redirected, see: https://github.com/apache/incubator/tree/master/assets/retired > Tuweni retired, but cleanup is incomplete > - > > Key: INCUBATOR-279 > URL: https://issues.apache.org/jira/browse/INCUBATOR-279 > Project: Incubator > Issue Type: Bug >Reporter: Sebb >Priority: Major > > The LDAP project list still needs to be removed. > Also podlings.xml and tuweni.xml need to be updated, and the website site > redirect needs to be set up. > Maybe the retirement instructions need to be reviewed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-280) Datalab retired, but cleanup is incomplete
[ https://issues.apache.org/jira/browse/INCUBATOR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790239#comment-17790239 ] Sebb commented on INCUBATOR-280: Still not complete. The website needs to be redirected; see [https://github.com/apache/incubator/tree/master/assets/retired] > Datalab retired, but cleanup is incomplete > -- > > Key: INCUBATOR-280 > URL: https://issues.apache.org/jira/browse/INCUBATOR-280 > Project: Incubator > Issue Type: Task >Reporter: Sebb >Priority: Major > > As the subject says -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[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=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=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] [Resolved] (WHIMSY-386) public_ldap_committees is redundant
[ https://issues.apache.org/jira/browse/WHIMSY-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved WHIMSY-386. - Resolution: Fixed Gone, not sure when... > public_ldap_committees is redundant > --- > > Key: WHIMSY-386 > URL: https://issues.apache.org/jira/browse/WHIMSY-386 > Project: Whimsy > Issue Type: Task >Reporter: Sebb >Priority: Major > > The public_ldap_committees.json file has long been deprecated, and AFAICT it > is not being used. It should be dropped. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (WHIMSY-406) Roster modify may fail to list selected committer(s)
Sebb created WHIMSY-406: --- Summary: Roster modify may fail to list selected committer(s) Key: WHIMSY-406 URL: https://issues.apache.org/jira/browse/WHIMSY-406 Project: Whimsy Issue Type: Bug Reporter: Sebb See https://lists.apache.org/thread/w27gsgddjx7ob1nhw3cqqzcw9hq981c3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WHIMSY-401) Board agenda tool comments
[ https://issues.apache.org/jira/browse/WHIMSY-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved WHIMSY-401. - Resolution: Information Provided > Board agenda tool comments > -- > > Key: WHIMSY-401 > URL: https://issues.apache.org/jira/browse/WHIMSY-401 > Project: Whimsy > Issue Type: Task > Components: BoardAgenda >Reporter: Craig L Russell >Priority: Major > > The agenda tool allows users to add comments to the agenda which are saved in > the agenda and are subsequently sent to the project PMC private list. The > comments are durable in the agenda and can be viewed in subsequent agendas. > The agenda tool should allow comments to be divided into multiple categories, > depending on the intended audience: > feedback: congratulations, nice report, healthy community > discussion: notes for other Directors about the project that might lead to > future action > request: information is needed from the project, possibly to clarify an item > in the report > action: the project is requested to perform some corrective action > Additionally, a Director might want to flag the report for the upcoming board > meeting > Proposal: > 1. Update the comment pop-up dialog to add a drop-down called *Category* to > select one of four categories: > [ ] feedback > [X] discuss is default > [ ] request > [ ] action > Text entered as "feedback" will be sent unmodified to the PMC private list. > It will be stored in the agenda unmodified. > Text entered as "discuss" will not be sent to the PMC private list. It will > be stored in the agenda with a prefix of [discuss] > Text entered as "request" will be sent to the PMC with a prefix "Please reply > to this request" and will be stored in the agenda with a prefix of [request] > Text entered as "action" will be sent to the PMC with a prefix "Please take > the requested action" and will be stored in the agenda with a prefix of > [action] > 2. The field "Initials" will be changed to "From" > 3. Directors will be able to edit current comments by clicking on the author > of a current comment, regardless of the author. This will bring up a comment > pop-up allowing editing of any of the fields, e.g. to change the "From" from > "clr" to "board"; or to change the Category; or to update the text of the > comment. > The action boxes at the bottom of the pop-up will additionally allow [Delete > Comment] as an option (in addition to [Cancel] and [Save]) -- 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=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=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=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=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=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=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=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 > > OpenSslCryptoRandom.isNativeCodeEnabled() currently throws an Exception if > the native cannout be found -- This message was sent by
[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=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] [Commented] (INCUBATOR-281) Broken link
[ https://issues.apache.org/jira/browse/INCUBATOR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787418#comment-17787418 ] Sebb commented on INCUBATOR-281: Noticed a blank line where sibling pages had a date, so I restored the date lost in the last commit. The page as been regenerated. Looks like there needs to be a check of the build to detect such failings. > Broken link > --- > > Key: INCUBATOR-281 > URL: https://issues.apache.org/jira/browse/INCUBATOR-281 > Project: Incubator > Issue Type: Bug >Reporter: Sebb >Priority: Major > > https://cwiki.apache.org/confluence/display/incubator/RetiringPodlings > links to > https://incubator.apache.org/guides/retirement.html > which does not exist. > Not sure whether it ever did exist. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Created] (INCUBATOR-281) Broken link
Sebb created INCUBATOR-281: -- Summary: Broken link Key: INCUBATOR-281 URL: https://issues.apache.org/jira/browse/INCUBATOR-281 Project: Incubator Issue Type: Bug Reporter: Sebb https://cwiki.apache.org/confluence/display/incubator/RetiringPodlings links to https://incubator.apache.org/guides/retirement.html which does not exist. Not sure whether it ever did exist. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Resolved] (ATTIC-219) add attic banner to datalab website
[ https://issues.apache.org/jira/browse/ATTIC-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved ATTIC-219. Resolution: Invalid The Attic is not responsible for podlings. > add attic banner to datalab website > --- > > Key: ATTIC-219 > URL: https://issues.apache.org/jira/browse/ATTIC-219 > Project: Attic > Issue Type: Project >Reporter: PJ Fanning >Priority: Major > > This project has been retired. See > https://issues.apache.org/jira/browse/INCUBATOR-280 and > https://lists.apache.org/thread/otdgll1z139qphnon0n2ynt83rtcwb7l -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (INCUBATOR-280) Datalab retired, but cleanup is incomplete
[ https://issues.apache.org/jira/browse/INCUBATOR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786220#comment-17786220 ] Sebb commented on INCUBATOR-280: The Incubator PMC is ultimately responsible. Some parts have to be done by Infra on request from the IPMC. > Datalab retired, but cleanup is incomplete > -- > > Key: INCUBATOR-280 > URL: https://issues.apache.org/jira/browse/INCUBATOR-280 > Project: Incubator > Issue Type: Task >Reporter: Sebb >Priority: Major > > As the subject says -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-280) Datalab retired, but cleanup is incomplete
[ https://issues.apache.org/jira/browse/INCUBATOR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785867#comment-17785867 ] Sebb commented on INCUBATOR-280: AFAIK, nothing has been done on this. For example, the LDAP group still exists https://dist.apache.org/repos/dist/dev/incubator/datalab/ still exists Various resources such as Git, Website, Wiki appear to be still active (they should have comments to say the podling is retired) etc. > Datalab retired, but cleanup is incomplete > -- > > Key: INCUBATOR-280 > URL: https://issues.apache.org/jira/browse/INCUBATOR-280 > Project: Incubator > Issue Type: Task >Reporter: Sebb >Priority: Major > > As the subject says -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[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=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=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=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)
