Re: [ANN] Apache Commons Compress 1.18 Released

[Gary Gregory]

Subject line should read "1.19", not "1.18".

G

On Tue, Aug 27, 2019 at 2:35 PM Stefan Bodewig  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The Apache Commons Team is pleased to announce the release of Apache
> Commons Compress 1.19.
>
> Apache Commons Compress software defines an API for working with
> compression and archive formats.  These include: bzip2, gzip, pack200,
> lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4,
> Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj.
>
> This release is mostly a bugfix release, for a full list of changes see
> below.
>
> ZipArchiveInputStream and ZipFile will no longer throw an exception if
> an extra field generally understood by Commons Compress is malformed
> but rather turn them into UnrecognizedExtraField instances.  You can
> influence the way extra fields are parsed in more detail by using the
> new getExtraFields(ExtraFieldParsingBehavior) method of
> ZipArchiveEntry now.
>
> Some of the ZIP extra fields related to strong encryption will now
> throw ZipExceptions rather than ArrayIndexOutOfBoundsExceptions in
> certain cases when used directly. There is no practical difference
> when they are read via ZipArchiveInputStream or ZipFile.
>
> Source and binary distributions are available for download from the
> Apache Commons download site:
>
> https://commons.apache.org/proper/commons-compress/download_compress.cgi
>
> When downloading, please verify signatures using the KEYS file available
> at the above location when downloading the release.
>
> Changes in this version include:
>
> New features:
> o It is now possible to skip parsing of local file headers when
>   using ZipFile which may speed up reading the archive at the
>   cost of potentially missing important information. See the
>   javadocs of the ZipFile class for details.
>   Issue: COMPRESS-466.
> o TarArchiveInputStream has a new constructor-arg lenient that
>   can be used to accept certain broken archives.
>   Issue: COMPRESS-469.
> o ArjArchiveEntry and SevenZArchiveEntry now implement hashCode
>   and equals.
>   Issue: COMPRESS-475.
> o Added a MultiReadOnlySeekableByteChannel class
>   that can be used to concatenate the parts of a multi volume 7z
>   archive so that SevenZFile can read them.
>   Issue: COMPRESS-231.
>   Thanks to Tim Underwood.
>
> Fixed Bugs:
> o ZipArchiveInputStream could forget the compression level has
>   changed under certain circumstances.
> o Fixed another potential resource leak in
>   ParallelScatterZipCreator#writeTo.
>   Issue: COMPRESS-470.
> o ArArchiveInputStream could think it had hit EOF prematurely.
>   Github Pull Request #74.
>   Thanks to Alex Bertram.
> o Throw IOException rather than RuntimeExceptions for certain
>   malformed LZ4 or Snappy inputs.
>   Issue: COMPRESS-490.
> o ZipArchiveInputStream failed to read stored entries with a
>   data descriptor if the data descriptor didn't use the
>   signature invented by InfoZIP.
>   Issue: COMPRESS-482.
>
> Changes:
> o SevenZFile now provides a way to cap memory consumption for
>   LZMA(2) compressed content.
>   Github Pull Request #76.
>   Issue: COMPRESS-481.
>   Thanks to Robin Schimpf.
> o The ARJ package has been updated to contain constants for more
>   recent specifications.
>   Issue: COMPRESS-464.
>   Thanks to Rostislav Krasny.
> o Update optional library zstd-jni from 1.3.3-3 to 1.4.0-1.
>   Issue: COMPRESS-484.
> o ParallelScatterZipCreator now writes the entries to the
>   gathered output in the same order they have been added.
>   Github Pull Requests #78 and #79.
>   Issue: COMPRESS-485.
>   Thanks to Hervé Boutemy, Tibor Digana.
> o The Expander and Archive example classes can leak resources
>   they have wrapped around passed in streams or channels. The
>   methods consuming streams and channels have been adapted to
>   give the calling code a chance to deal with those wrapper
>   resources.
>   Issue: COMPRESS-486.
> o ZipArchiveInputStream and ZipFile no longer assume Commons
>   Compress would understand extra fields better than the writer
>   of the archive and silently turn extra fields that Commons
>   Compress should understand into UnrecognizedExtraFields if
>   parsing said fields fails.
>   It is now possible to take more control over the extra field
>   parsing process with a new overload of
>   ZipArchiveEntry#getExtraFields.
>   Issue: COMPRESS-479.
> o ZipArchiveInputStream will now throw an exception if reading a
>   stored entry with a data descriptor and the data descriptor
>   doesn't match what it has actually read.
>
>   The most common case for a situation like this is a stored ZIP
>   archive inside of the archive ZipArchiveInputStream currently
>   reads. In such a case ZipArchiveInputStream would happily
>   extract the contained archive and stop once the central
>   directory of the inner archive has been hit. This is a case
>   where ZipArchiveInputStream simply can not be used and only
>   ZipFile is able 

Re: commons-configurations2 doesn't strip double quotes in env variable

[Oliver Heger]

Hello Duc,

the problem you are facing is probably not related to double quotes, but
to a change in the way delimiter characters in strings are handled.

In configuration 2.x the splitting of strings at delimiter characters is
disabled per default. But you can enable this feature by setting a
suitable ListDelimiterHandler. This is described in the user's guide [1].

HTH
Oliver

[1]
http://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#List_handling

Am 23.08.19 um 05:04 schrieb Duc Tran:
> Hello, I'm Duc, and in our projects, we just upgraded from
> commons-configuration 1.9 to 2.5 and we found that when passing env
> variables into properties file as a list like
> `key=${env:MY_LIST_VARIABLES}` where MY_LIST_VARIABLES is "value1,
> value2, value3", the new commons configuration 2.5 doesn't strip double
> quotes. This makes `properites.getStringArray("key")` returns an array
> with only element is the big string ["value1, value2, value3"] instead
> of what I expected and what the commons-configuration 1 does returns
> ["value1", "value2", "value3"]
> 
> So, do you have any suggestion to keep that behavior with
> commons-configuration 2.5?
> 
> 
> Thank you!
> 
> Duc Tran Tien,
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[CVE-2019-12402] Apache Commons Compress denial of service vulnerability

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Severity: Low

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Commons Compress 1.15 to 1.18

Description:
The file name encoding algorithm used internally in Apache Commons
Compress can get into an infinite loop when faced with specially
crafted inputs. This can lead to a denial of service attack if an
attacker can choose the file names inside of an archive created by
Compress.

Mitigation:
Commons Compress users should upgrade to 1.19 or later.

Credit:
This issue was discovered by Masaya Suzuki of Google.

References:
https://commons.apache.org/proper/commons-compress/security-reports.html

Stefan Bodewig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAl1lgKIACgkQohFa4V9ri3IsSwCg0tYlFA5WXy6EuHFtRjsbVofR
WjAAn2uNwEELGpIR2JiRO+jEAyxQJZvV
=Ds0n
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANN] Apache Commons Compress 1.19 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Re-Sending with fixed subject, sorry]

The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.19.

Apache Commons Compress software defines an API for working with
compression and archive formats.  These include: bzip2, gzip, pack200,
lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4,
Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj.

This release is mostly a bugfix release, for a full list of changes see
below.

ZipArchiveInputStream and ZipFile will no longer throw an exception if
an extra field generally understood by Commons Compress is malformed
but rather turn them into UnrecognizedExtraField instances.  You can
influence the way extra fields are parsed in more detail by using the
new getExtraFields(ExtraFieldParsingBehavior) method of
ZipArchiveEntry now.

Some of the ZIP extra fields related to strong encryption will now
throw ZipExceptions rather than ArrayIndexOutOfBoundsExceptions in
certain cases when used directly. There is no practical difference
when they are read via ZipArchiveInputStream or ZipFile.

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-compress/download_compress.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in this version include:

New features:
o It is now possible to skip parsing of local file headers when
  using ZipFile which may speed up reading the archive at the
  cost of potentially missing important information. See the
  javadocs of the ZipFile class for details.
  Issue: COMPRESS-466.
o TarArchiveInputStream has a new constructor-arg lenient that
  can be used to accept certain broken archives.
  Issue: COMPRESS-469.
o ArjArchiveEntry and SevenZArchiveEntry now implement hashCode
  and equals.
  Issue: COMPRESS-475.
o Added a MultiReadOnlySeekableByteChannel class
  that can be used to concatenate the parts of a multi volume 7z
  archive so that SevenZFile can read them.
  Issue: COMPRESS-231.
  Thanks to Tim Underwood.

Fixed Bugs:
o ZipArchiveInputStream could forget the compression level has
  changed under certain circumstances.
o Fixed another potential resource leak in
  ParallelScatterZipCreator#writeTo.
  Issue: COMPRESS-470.
o ArArchiveInputStream could think it had hit EOF prematurely.
  Github Pull Request #74.
  Thanks to Alex Bertram.
o Throw IOException rather than RuntimeExceptions for certain
  malformed LZ4 or Snappy inputs.
  Issue: COMPRESS-490.
o ZipArchiveInputStream failed to read stored entries with a
  data descriptor if the data descriptor didn't use the
  signature invented by InfoZIP.
  Issue: COMPRESS-482.

Changes:
o SevenZFile now provides a way to cap memory consumption for
  LZMA(2) compressed content.
  Github Pull Request #76.
  Issue: COMPRESS-481.
  Thanks to Robin Schimpf.
o The ARJ package has been updated to contain constants for more
  recent specifications.
  Issue: COMPRESS-464.
  Thanks to Rostislav Krasny.
o Update optional library zstd-jni from 1.3.3-3 to 1.4.0-1.
  Issue: COMPRESS-484.
o ParallelScatterZipCreator now writes the entries to the
  gathered output in the same order they have been added.
  Github Pull Requests #78 and #79.
  Issue: COMPRESS-485.
  Thanks to Hervé Boutemy, Tibor Digana.
o The Expander and Archive example classes can leak resources
  they have wrapped around passed in streams or channels. The
  methods consuming streams and channels have been adapted to
  give the calling code a chance to deal with those wrapper
  resources.
  Issue: COMPRESS-486.
o ZipArchiveInputStream and ZipFile no longer assume Commons
  Compress would understand extra fields better than the writer
  of the archive and silently turn extra fields that Commons
  Compress should understand into UnrecognizedExtraFields if
  parsing said fields fails.
  It is now possible to take more control over the extra field
  parsing process with a new overload of
  ZipArchiveEntry#getExtraFields.
  Issue: COMPRESS-479.
o ZipArchiveInputStream will now throw an exception if reading a
  stored entry with a data descriptor and the data descriptor
  doesn't match what it has actually read.

  The most common case for a situation like this is a stored ZIP
  archive inside of the archive ZipArchiveInputStream currently
  reads. In such a case ZipArchiveInputStream would happily
  extract the contained archive and stop once the central
  directory of the inner archive has been hit. This is a case
  where ZipArchiveInputStream simply can not be used and only
  ZipFile is able to read the archive.

  The only other explanation is a broken archive. So the
  exception prevents users from thinking they had successfully
  read the contents of the archive.
  Issue: COMPRESS-483.
o The 7zip tools provide a default name for archive entries
  without name; 

[ANN] Apache Commons Compress 1.18 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.19.

Apache Commons Compress software defines an API for working with
compression and archive formats.  These include: bzip2, gzip, pack200,
lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4,
Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj.

This release is mostly a bugfix release, for a full list of changes see
below.

ZipArchiveInputStream and ZipFile will no longer throw an exception if
an extra field generally understood by Commons Compress is malformed
but rather turn them into UnrecognizedExtraField instances.  You can
influence the way extra fields are parsed in more detail by using the
new getExtraFields(ExtraFieldParsingBehavior) method of
ZipArchiveEntry now.

Some of the ZIP extra fields related to strong encryption will now
throw ZipExceptions rather than ArrayIndexOutOfBoundsExceptions in
certain cases when used directly. There is no practical difference
when they are read via ZipArchiveInputStream or ZipFile.

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-compress/download_compress.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in this version include:

New features:
o It is now possible to skip parsing of local file headers when
  using ZipFile which may speed up reading the archive at the
  cost of potentially missing important information. See the
  javadocs of the ZipFile class for details.
  Issue: COMPRESS-466.
o TarArchiveInputStream has a new constructor-arg lenient that
  can be used to accept certain broken archives.
  Issue: COMPRESS-469.
o ArjArchiveEntry and SevenZArchiveEntry now implement hashCode
  and equals.
  Issue: COMPRESS-475.
o Added a MultiReadOnlySeekableByteChannel class
  that can be used to concatenate the parts of a multi volume 7z
  archive so that SevenZFile can read them.
  Issue: COMPRESS-231.
  Thanks to Tim Underwood.

Fixed Bugs:
o ZipArchiveInputStream could forget the compression level has
  changed under certain circumstances.
o Fixed another potential resource leak in
  ParallelScatterZipCreator#writeTo.
  Issue: COMPRESS-470.
o ArArchiveInputStream could think it had hit EOF prematurely.
  Github Pull Request #74.
  Thanks to Alex Bertram.
o Throw IOException rather than RuntimeExceptions for certain
  malformed LZ4 or Snappy inputs.
  Issue: COMPRESS-490.
o ZipArchiveInputStream failed to read stored entries with a
  data descriptor if the data descriptor didn't use the
  signature invented by InfoZIP.
  Issue: COMPRESS-482.

Changes:
o SevenZFile now provides a way to cap memory consumption for
  LZMA(2) compressed content.
  Github Pull Request #76.
  Issue: COMPRESS-481.
  Thanks to Robin Schimpf.
o The ARJ package has been updated to contain constants for more
  recent specifications.
  Issue: COMPRESS-464.
  Thanks to Rostislav Krasny.
o Update optional library zstd-jni from 1.3.3-3 to 1.4.0-1.
  Issue: COMPRESS-484.
o ParallelScatterZipCreator now writes the entries to the
  gathered output in the same order they have been added.
  Github Pull Requests #78 and #79.
  Issue: COMPRESS-485.
  Thanks to Hervé Boutemy, Tibor Digana.
o The Expander and Archive example classes can leak resources
  they have wrapped around passed in streams or channels. The
  methods consuming streams and channels have been adapted to
  give the calling code a chance to deal with those wrapper
  resources.
  Issue: COMPRESS-486.
o ZipArchiveInputStream and ZipFile no longer assume Commons
  Compress would understand extra fields better than the writer
  of the archive and silently turn extra fields that Commons
  Compress should understand into UnrecognizedExtraFields if
  parsing said fields fails.
  It is now possible to take more control over the extra field
  parsing process with a new overload of
  ZipArchiveEntry#getExtraFields.
  Issue: COMPRESS-479.
o ZipArchiveInputStream will now throw an exception if reading a
  stored entry with a data descriptor and the data descriptor
  doesn't match what it has actually read.

  The most common case for a situation like this is a stored ZIP
  archive inside of the archive ZipArchiveInputStream currently
  reads. In such a case ZipArchiveInputStream would happily
  extract the contained archive and stop once the central
  directory of the inner archive has been hit. This is a case
  where ZipArchiveInputStream simply can not be used and only
  ZipFile is able to read the archive.

  The only other explanation is a broken archive. So the
  exception prevents users from thinking they had successfully
  read the contents of the archive.
  Issue: COMPRESS-483.
o The 7zip tools provide a default name for archive entries
  without name; SevenZFile returns a null name for such
  

Re: [email] Is there a way to unset CC/BCC?

[Siegfried Goeschl]

Hi Pavlo,

many years ago (15?) ago I build some email service where it was very useful to 
avoid sending real emails to real customers during tests or write the emails to 
disk.

My entry point was

4 

 /**
1485 

  * Sends the email. Internally we build a MimeMessage
1486 

  * which is afterwards sent to the SMTP server.
1487 

  *
1488 

  * @return the message id of the underlying MimeMessage
1489 

  * @throws IllegalStateException if the MimeMessage was already built, ie 
{@link #buildMimeMessage()}
1490 

  *   was already called
1491 

  * @throws EmailException the sending failed
1492 

  */
1493 

 public String send() throws EmailException
1494 

 {
1495 

 this.buildMimeMessage();
1496 

 return this.sendMimeMessage();
1497 

 }

So there is a clear distinction between building the MimeMessage and sending it 
- so this might help

Thanks in advance, 

Siegfried Goeschl


> On 27 Aug 2019, at 15:34, sebb  wrote:
> 
> On Tue, 27 Aug 2019 at 12:02, Pavlo Polishchuk  wrote:
>> 
>> Good day,
>> Is there a way to unset CC/BCC through "org.apache.commons.mail.Email" ?
>> 
>> I tried "email.setCC" with empty collection but there is a check for
>> null/empty collection inside.
>> Also, tried to "email.getMimeMessage().setRecipients(...)" but this fails
>> with NPE since MimeMessage is not build at that time.
>> 
>> Do I miss something?
> 
> The underlying list is accessible as a protected field and via code of the 
> form:
> 
> List list = email.getBccAddresses();
> 
> so it's easy enough to clear the list if required.
> 
> An alternative is not to set the list in the first place ...
> 
>> Thanks in advance!
>> 
>> --
>> Best regards,
>> Paul
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

Re: [email] Is there a way to unset CC/BCC?

[sebb]

On Tue, 27 Aug 2019 at 12:02, Pavlo Polishchuk  wrote:
>
> Good day,
> Is there a way to unset CC/BCC through "org.apache.commons.mail.Email" ?
>
> I tried "email.setCC" with empty collection but there is a check for
> null/empty collection inside.
> Also, tried to "email.getMimeMessage().setRecipients(...)" but this fails
> with NPE since MimeMessage is not build at that time.
>
> Do I miss something?

The underlying list is accessible as a protected field and via code of the form:

List list = email.getBccAddresses();

so it's easy enough to clear the list if required.

An alternative is not to set the list in the first place ...

> Thanks in advance!
>
> --
> Best regards,
> Paul

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[email] Is there a way to unset CC/BCC?

[Pavlo Polishchuk]

Good day,
Is there a way to unset CC/BCC through "org.apache.commons.mail.Email" ?

I tried "email.setCC" with empty collection but there is a check for
null/empty collection inside.
Also, tried to "email.getMimeMessage().setRecipients(...)" but this fails
with NPE since MimeMessage is not build at that time.

Do I miss something?
Thanks in advance!

-- 
Best regards,
Paul