All,
Please consider the following for Apache Commons VFS2 version 2.1 (rc2).
Maven repository:
https://repository.apache.org/content/repositories/orgapachecommons-1166
Artifacts: https://dist.apache.org/repos/dist/dev/commons/vfs/ r13608
MD5 commons-vfs-distribution-2.1-bin.tar.gz
8cc35a3169e
I filed MPOM-118 so maybe we can have this ASF-wide.
I wouldn't even know how to make gpg generate multiple signatures with
different algorithms from the command-line, so yeah, setting this option
would just do SHA512 for the algorithm used in the signature. The separate
non-GPG hashes (.md5, .sha1
sebb wrote:
On 11 May 2016 at 15:49, Josh Elser wrote:
> Well, I'd ask that you tell me what you think is wrong in what currently
> exists. I did what you asked for rc1 already, but apparently you still find
> it insufficient?
The RN section which mentioned the compatibility issues was b
and for KISS, can we make it generate only SHA512 (not MD5, not SHA1)?
Gary
On Wed, May 11, 2016 at 8:03 AM, Christopher wrote:
> maven-gpg-plugin simply does a pass-through to the underlying gpg
> command-line, with something like the following options:
> gpg -a --detach-sign filename
>
> So,
On 11 May 2016 at 15:49, Josh Elser wrote:
> Well, I'd ask that you tell me what you think is wrong in what currently
> exists. I did what you asked for rc1 already, but apparently you still find
> it insufficient?
The RN section which mentioned the compatibility issues was buried at
the end of a
maven-gpg-plugin simply does a pass-through to the underlying gpg
command-line, with something like the following options:
gpg -a --detach-sign filename
So, it's normally using whatever the user's personal settings are for the
digest algorithm. Hopefully that's the best available (SHA512), but it
Well, I'd ask that you tell me what you think is wrong in what currently
exists. I did what you asked for rc1 already, but apparently you still
find it insufficient?
sebb wrote:
Please ensure that the changes description and therefore RN contain
details of why we think the Clirr errors are not
Please ensure that the changes description and therefore RN contain
details of why we think the Clirr errors are not BC errors.
I don't have time just now, but I may be able to update them later today.
On 11 May 2016 at 05:06, Gary Gregory wrote:
> Don't despair, I plan on being +1 for the next
