[jira] [Updated] (IO-801) Deprecation documentation gives incorrect alternative
[
https://issues.apache.org/jira/browse/IO-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Howe updated IO-801:
--
Description:
For example, the constructors for {{ReversedLinesFileReader}} say
{quote}Use {{ReaderInputStream.builder()}} instead{quote}
when the replacement is actually {{ReversedLinesFileReader.builder()}}.
was:
For example, the constructors for `ReversedLinesFileReader` say
> Use `ReaderInputStream.builder()` instead
when the replacement is actually `ReversedLinesFileReader.builder()`.
> Deprecation documentation gives incorrect alternative
> -
>
> Key: IO-801
> URL: https://issues.apache.org/jira/browse/IO-801
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.13.0
>Reporter: James Howe
>Priority: Minor
>
> For example, the constructors for {{ReversedLinesFileReader}} say
> {quote}Use {{ReaderInputStream.builder()}} instead{quote}
> when the replacement is actually {{ReversedLinesFileReader.builder()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IO-801) Deprecation documentation gives incorrect alternative
James Howe created IO-801: - Summary: Deprecation documentation gives incorrect alternative Key: IO-801 URL: https://issues.apache.org/jira/browse/IO-801 Project: Commons IO Issue Type: Bug Components: Streams/Writers Affects Versions: 2.13.0 Reporter: James Howe For example, the constructors for `ReversedLinesFileReader` say > Use `ReaderInputStream.builder()` instead when the replacement is actually `ReversedLinesFileReader.builder()`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-556) Unexpected behavior of FileNameUtils.normalize may lead to limited path traversal vulnerabilies
[
https://issues.apache.org/jira/browse/IO-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326527#comment-17326527
]
James Howe commented on IO-556:
---
Was ** 2.2 when this was introduced, or does it go back to 1.4 etc. as
CVE-2021-29425 says?
> Unexpected behavior of FileNameUtils.normalize may lead to limited path
> traversal vulnerabilies
> ---
>
> Key: IO-556
> URL: https://issues.apache.org/jira/browse/IO-556
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.2, 2.3, 2.4, 2.5, 2.6
> Environment: all
>Reporter: Lukas Euler
>Priority: Major
> Labels: security, security-issue
>
> I sent this report in an Email to secur...@apache.org on 2017-10-16. I did
> not receive any kind of response yet (2017-11-18 as of writing). I am now
> posting it publicly, to open the issue up for discussion, and hopefully
> initiate a fix.
> This report is not about a vulnerability in {{commons-io}} per se, but an
> unexpected behavior that has a high chance of introducing a path traversal
> vulnerability when using {{FileNameUtils.normalize}} to sanitize user input.
> The traversal is limited to a single out-of-bounds-stepping "/../" segment.
> h5. Reproduction
> {Code}
> FileNameUtils.normalize("//../foo");// returns "//../foo" or
> "..\\foo", based on java.io.File.separatorChar
> FileNameUtils.normalize("..\\foo");// returns "//../foo" or
> "..\\foo", based on java.io.File.separatorChar
> {Code}
> h5. Possible impact (example)
> Consider a web-application that uses {{FileNameUtils.normalize}} to sanitize
> a user-supplied file name string, and then appends the sanitized value to a
> configured upload directory to store the uploaded content in:
> {Code}
> String fileName = "//../foo";// actually user-supplied (e.g. from
> multipart-POST request)
> fileName = FileNameUtils.normalize(fileName);// still holds the same
> value ("//../foo")
>
> if (fileName != null) {
> File newFile = new File("/base/uploads", fileName);// java.io.File
> treats double forward slashes as singles
> // newFile now points to
> "/base/uploads//../foo"
> newFile = newFile.getCanonicalFile();// newFile now points to
> "/base/foo", which should be inaccessible
> // Write contents to newFile...
> } else {
> // Assume malicious activity, handle error
> }
> {Code}
> h5. Relevant code locations
> * {{org.apache.commons.io.FilenameUtils#getPrefixLength}} : everything
> between a leading "//" and the next "/" is treated as a UNC server name, and
> ignored in all further validation logic of
> {{org.apache.commons.io.FilenameUtils#doNormalize}} .
> h5. Discussion
> One might argue that the given example is a misuse of the
> {{FileNameUtils.normalize}} method, and that everyone using it should expect
> absolute paths, full UNC paths, etc. to be returned by the method.
> Furthermore, the vulnerability can only occur due to the lax behavior of
> {{java.io.File}} .
> On the other hand, I believe that the JavaDoc of {{FileNameUtils.normalize}}
> suggests to most readers, that this method is exactly what is needed to
> sanitize file names:
> {noformat}
> //---
> /**
> * Normalizes a path, removing double and single dot path steps,
> * and removing any final directory separator.
> *
> * This method normalizes a path to a standard format.
> * The input may contain separators in either Unix or Windows format.
> * The output will contain separators in the format of the system.
> *
> * A trailing slash will be removed.
> * A double slash will be merged to a single slash (but UNC names are
> handled).
> * A single dot path segment will be removed.
> * A double dot will cause that path segment and the one before to be
> removed.
> * If the double dot has no parent path segment to work with, {@code null}
> * is returned.
> *
> * The output will be the same on both Unix and Windows except
> * for the separator character.
> *
> * /foo// -- /foo
> * /foo/./ -- /foo
> * /foo/../bar -- /bar
> * /foo/../bar/ -- /bar
> * /foo/../bar/../baz -- /baz
> * //foo//./bar -- /foo/bar
> * /../ -- null
> * ../foo -- null
> * foo/bar/.. -- foo
> * foo/../../bar-- null
> * foo/../bar -- bar
> * //server/foo/../bar -- //server/bar
> * //server/../bar -- null
> * C:\foo\..\bar
[jira] [Comment Edited] (IO-556) Unexpected behavior of FileNameUtils.normalize may lead to limited path traversal vulnerabilies
[
https://issues.apache.org/jira/browse/IO-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326527#comment-17326527
]
James Howe edited comment on IO-556 at 4/21/21, 1:19 PM:
-
Was 2.2 when this was introduced, or does it go back to 1.4 etc. as
CVE-2021-29425 says?
was (Author: jameshowe):
Was ** 2.2 when this was introduced, or does it go back to 1.4 etc. as
CVE-2021-29425 says?
> Unexpected behavior of FileNameUtils.normalize may lead to limited path
> traversal vulnerabilies
> ---
>
> Key: IO-556
> URL: https://issues.apache.org/jira/browse/IO-556
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.2, 2.3, 2.4, 2.5, 2.6
> Environment: all
>Reporter: Lukas Euler
>Priority: Major
> Labels: security, security-issue
>
> I sent this report in an Email to secur...@apache.org on 2017-10-16. I did
> not receive any kind of response yet (2017-11-18 as of writing). I am now
> posting it publicly, to open the issue up for discussion, and hopefully
> initiate a fix.
> This report is not about a vulnerability in {{commons-io}} per se, but an
> unexpected behavior that has a high chance of introducing a path traversal
> vulnerability when using {{FileNameUtils.normalize}} to sanitize user input.
> The traversal is limited to a single out-of-bounds-stepping "/../" segment.
> h5. Reproduction
> {Code}
> FileNameUtils.normalize("//../foo");// returns "//../foo" or
> "..\\foo", based on java.io.File.separatorChar
> FileNameUtils.normalize("..\\foo");// returns "//../foo" or
> "..\\foo", based on java.io.File.separatorChar
> {Code}
> h5. Possible impact (example)
> Consider a web-application that uses {{FileNameUtils.normalize}} to sanitize
> a user-supplied file name string, and then appends the sanitized value to a
> configured upload directory to store the uploaded content in:
> {Code}
> String fileName = "//../foo";// actually user-supplied (e.g. from
> multipart-POST request)
> fileName = FileNameUtils.normalize(fileName);// still holds the same
> value ("//../foo")
>
> if (fileName != null) {
> File newFile = new File("/base/uploads", fileName);// java.io.File
> treats double forward slashes as singles
> // newFile now points to
> "/base/uploads//../foo"
> newFile = newFile.getCanonicalFile();// newFile now points to
> "/base/foo", which should be inaccessible
> // Write contents to newFile...
> } else {
> // Assume malicious activity, handle error
> }
> {Code}
> h5. Relevant code locations
> * {{org.apache.commons.io.FilenameUtils#getPrefixLength}} : everything
> between a leading "//" and the next "/" is treated as a UNC server name, and
> ignored in all further validation logic of
> {{org.apache.commons.io.FilenameUtils#doNormalize}} .
> h5. Discussion
> One might argue that the given example is a misuse of the
> {{FileNameUtils.normalize}} method, and that everyone using it should expect
> absolute paths, full UNC paths, etc. to be returned by the method.
> Furthermore, the vulnerability can only occur due to the lax behavior of
> {{java.io.File}} .
> On the other hand, I believe that the JavaDoc of {{FileNameUtils.normalize}}
> suggests to most readers, that this method is exactly what is needed to
> sanitize file names:
> {noformat}
> //---
> /**
> * Normalizes a path, removing double and single dot path steps,
> * and removing any final directory separator.
> *
> * This method normalizes a path to a standard format.
> * The input may contain separators in either Unix or Windows format.
> * The output will contain separators in the format of the system.
> *
> * A trailing slash will be removed.
> * A double slash will be merged to a single slash (but UNC names are
> handled).
> * A single dot path segment will be removed.
> * A double dot will cause that path segment and the one before to be
> removed.
> * If the double dot has no parent path segment to work with, {@code null}
> * is returned.
> *
> * The output will be the same on both Unix and Windows except
> * for the separator character.
> *
> * /foo// -- /foo
> * /foo/./ -- /foo
> * /foo/../bar -- /bar
> * /foo/../bar/ -- /bar
> * /foo/../bar/../baz -- /baz
> * //foo//./bar -- /foo/bar
> * /../ -- null
> * ../foo -- null
> * foo/bar/.. -- foo
> * foo/../../bar
[jira] [Commented] (CODEC-259) Broken direct java.nio.ByteBuffer support in org.apache.commons.codec.binary.Hex
[
https://issues.apache.org/jira/browse/CODEC-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908002#comment-16908002
]
James Howe commented on CODEC-259:
--
Surely this should solve all {{ByteBuffer}} implementation issues?
{code:java}
protected static char[] encodeHex(final ByteBuffer data, final char[] toDigits)
{
byte[] bytes = new byte[data.capacity()];
data.get(bytes, 0, data.capacity());
return encodeHex(bytes, toDigits);
}
{code}
Arguably it should also change (or additional methods added) to consume a
buffer properly, obeying position and limit.
{code:java}
protected static char[] encodeHex(final ByteBuffer data, final char[] toDigits)
{
byte[] bytes = new byte[data.remaining()];
data.get(bytes);
return encodeHex(bytes, toDigits);
}
{code}
> Broken direct java.nio.ByteBuffer support in
> org.apache.commons.codec.binary.Hex
>
>
> Key: CODEC-259
> URL: https://issues.apache.org/jira/browse/CODEC-259
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.11, 1.12
>Reporter: Tomas Shestakov
>Priority: Major
> Fix For: 1.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.nio.ByteBuffer support in org.apache.commons.codec.binary.Hex does not
> work properly for direct ByteBuffer created by ByteBuffer.allocateDirectÂ
> method and for heap ByteBuffers which arrayOffset() or byteBuffer.position()
> greater than zero or byteBuffer.remaining() is not equal
> byteBuffer.array().{color:#660e7a}length{color}:
> This test will produce java.lang.UnsupportedOperationException
> {code:java}
> @Test
> public void testEncodeHexByteBufferEmpty() {
> assertTrue(Arrays.equals(new char[0],
> Hex.encodeHex(ByteBuffer.allocateDirect(0;
> }
> {code}
> This one will fail
> {code:java}
> @Test
> public void testEncodeHexByteBufferHelloWorldLowerCaseHex() {
> final ByteBuffer b = ByteBuffer.wrap(StringUtils.getBytesUtf8("[Hello
> World]"), 1, 11);
> final String expected = "48656c6c6f20576f726c64";
> char[] actual;
> actual = Hex.encodeHex(b);
> assertEquals(expected, new String(actual));
> actual = Hex.encodeHex(b, true);
> assertEquals(expected, new String(actual));
> actual = Hex.encodeHex(b, false);
> assertFalse(expected.equals(new String(actual)));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CODEC-261) Unable to encode read-only ByteBuffer
James Howe created CODEC-261:
Summary: Unable to encode read-only ByteBuffer
Key: CODEC-261
URL: https://issues.apache.org/jira/browse/CODEC-261
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.13
Reporter: James Howe
A read-only array-backed {{ByteBuffer}} fails to encode, because the backing
array is not accessible.
{code:java}
Hex.encodeHex(ByteBuffer.wrap(new byte[]{1}).asReadOnlyBuffer())
{code}
{noformat}
java.nio.ReadOnlyBufferException
at java.nio.ByteBuffer.array(ByteBuffer.java:996)
at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:213)
at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:172)
at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:140)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DBCP-351) setAutoCommit called too many times
[
https://issues.apache.org/jira/browse/DBCP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068061#comment-13068061
]
James Howe commented on DBCP-351:
-
Re. Dain's comment, there's only a transaction open if one has sent BEGIN
without then sending COMMIT/ROLLBACK, which should always have been done on
return to pool.
Would overall performance not be better if new connections are added to the
pool to replace disconnected ones, rather than adding all this extra traffic on
every request so that the existing connections can use autoReconnect?
setAutoCommit called too many times
---
Key: DBCP-351
URL: https://issues.apache.org/jira/browse/DBCP-351
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4
Reporter: OD
Fix For: 2.0
passivateObject in PoolableConnectionFactory sets autoCommit to true, even if
defaultAutoCommit is set to false. This results in two extra db queries for
every use of the connection (set false, do work, set true). This creates a
significant amount of overhead, even if the connection is never even used.
I propose it be changed to:
if(conn.getAutoCommit() != _defaultAutoCommit)
{
conn.setAutoCommit(_defaultAutoCommit);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
