[jira] [Updated] (JENA-1812) Migrate blank node hash algorithm from MD5 to SHA-256
[ https://issues.apache.org/jira/browse/JENA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1812: Fix Version/s: (was: Jena 3.14.0) Jena 3.15.0 > Migrate blank node hash algorithm from MD5 to SHA-256 > - > > Key: JENA-1812 > URL: https://issues.apache.org/jira/browse/JENA-1812 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ >Reporter: Nicolas Seydoux >Assignee: Andy Seaborne >Priority: Trivial > Labels: easyfix > Fix For: Jena 3.15.0 > > Original Estimate: 5m > Time Spent: 50m > Remaining Estimate: 0h > > MD5 is a deprecated hashing algorithm, and even though it is not used on > sensitive data in the context of Jena, its usage is picked up by security > softwares as a security flaw. This may reduce the incentive to use Jena in > commercial products, and computing SHA-256 hashes is not prohibitively more > expensive than MD5. > > Therefore, I suggest to migrate from using MD5 hashes to SHA-256. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JENA-1819) Updating from 3.12 to 3.13 breaks
[
https://issues.apache.org/jira/browse/JENA-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne closed JENA-1819.
---
> Updating from 3.12 to 3.13 breaks
> -
>
> Key: JENA-1819
> URL: https://issues.apache.org/jira/browse/JENA-1819
> Project: Apache Jena
> Issue Type: Bug
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade jena-arq from 3.12 to 3.13. The following code breaks.
> {code:java}
> public class TestJena {
>
> private static FastDateFormat timestamp =
> FastDateFormat.getInstance("HH:mm:ss.SSS") ;
>
> private void printQuery(Query query, QuerySolution initialBinding) {
> String time = DateTimeUtils.nowAsString(timestamp);
> System.err.print("~~ ");
> System.err.print(time);
> System.err.println(" ~~");
> System.err.println(initialBinding);
> System.err.print(query);
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> TestJena.java:[13,36] no suitable method found for
> nowAsString(org.apache.commons.lang3.time.FastDateFormat)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.lang.String) is not
> applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.lang.String)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.time.format.DateTimeFormatter)
> is not applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.time.format.DateTimeFormatter)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[RESULT] [VOTE] Apache Jena 3.14.0 RC 2
The vote passes with +1's from Aaron, Adam, Bruno, Andy Files now sync'ing. Andy On 16/01/2020 17:34, Andy Seaborne wrote: Hi, Here is a vote on the release of Apache Jena 3.14.0 This is the second proposed release candidate. The deadline is only 72hours in case there are enough +1 votes and I can do the final stage on Sunday - otherwise, it is likely to be mid next week. Changes from RC1: Fix for JENA-1817 https://github.com/apache/jena/commit/08ca0b83 Changes for 3.14.0: https://s.apache.org/jena-3.14.0-jira Release Vote Everyone, not just committers, is invited to test and vote. Please download and test the proposed release. Staging repository: https://repository.apache.org/content/repositories/orgapachejena-1036 Proposed dist/ area: https://dist.apache.org/repos/dist/dev/jena/ Keys: https://svn.apache.org/repos/asf/jena/dist/KEYS Git commit (browser URL): https://github.com/apache/jena/commit/d0abcd14 Git Commit Hash: d0abcd14f82c36045a3c047941a6518f3bdb56ce Git Commit Tag: jena-3.14.0 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open until at least Sunday, 19th January 2020 at 18:00 UTC If you expect to check the release but the time limit does not work for you, please email within the schedule above with an expected time and we can extend the vote period. Thanks, Andy Checking needed: + are the GPG signatures fine? + are the checksums correct? + is there a source archive? + can the source archive really be built? (NB This requires a "mvn install" first time) + is there a correct LICENSE and NOTICE file in each artifact (both source and binary artifacts)? + does the NOTICE file contain all necessary attributions? + have any licenses of dependencies changed due to upgrades? if so have LICENSE and NOTICE been upgraded appropriately? + does the tag/commit in the SCM contain reproducible sources?
