AW: [Bug 33169] KIndly update the date feature
> > Just curious about our bugzilla infrastructure - do random users get > > to change the content of these bugs, even if they aren't the ones who > > reported the issue? > > Yes. > > Back when Bugzilla was introduced the developers and admins falsely > assumed only sensible people would be using the tool. > > Stefan Do you know if JIRA is more secure? Also against spam attacks? If yes, we could about thinking to migrate ... Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Bug 33169] KIndly update the date feature
On Thu, 28 Jun 2018 at 11:43, Jan Matèrne (jhm) wrote: > > > Just curious about our bugzilla infrastructure - do random users get > > > to change the content of these bugs, even if they aren't the ones who > > > reported the issue? > > > > Yes. > > > > Back when Bugzilla was introduced the developers and admins falsely > > assumed only sensible people would be using the tool. > > > > Stefan > > Do you know if JIRA is more secure? > Also against spam attacks? > If yes, we could about thinking to migrate ... > > Jan > Jira has roles [1]; Bugzilla has groups, but I cannot figure out whether they could be as flexible or easy to administrate. Gintas [1] https://confluence.atlassian.com/jirakb/jira-permissions-made-simple-717062767.html
Re: [Bug 33169] KIndly update the date feature
On 2018-06-28, Jan Matèrne (jhm) wrote: >>> Just curious about our bugzilla infrastructure - do random users get >>> to change the content of these bugs, even if they aren't the ones who >>> reported the issue? >> Yes. >> Back when Bugzilla was introduced the developers and admins falsely >> assumed only sensible people would be using the tool. > Do you know if JIRA is more secure? Depends on what "secure" means. The ASF installations allow everybody to create accounts and everybody to create new issues. This is a deliberate choice and is the same for JIRA and Bugzilla - and is the best choice for an open source project IMHO. I'm not sure whether JIRA allows arbitrary users to modify existing issues ither people have created. Of course you want everybody to be able to comment, not so sure about the issue's title. I've just had a look at the permissions on Commons Compress' JIRA project and "edit issue" can only be done by people in certain roles while "create issue" is allowed to the jira-users group - which is everybody with an account. > Also against spam attacks? When I complained too much about Bugzilla spam I was granted Admin access so I could block spammers. :-) I recall JIRA spam as well but it doesn't happen very often. Maybe the account creation procedure for JIRA is more involved than for Bugzilla so setting up accounts is more work for spammers and they prefer Bugzilla as the easier target. I don't know. TBH I don't think there is a big difference and we seem to be able to handle spam reasonably well. > If yes, we could about thinking to migrate ... I'm afraid a migration of the existing issues would be painful and we've got a LONG history with lots of issues in Bugzilla. I'm not convinced this kind of issue hijacking is happenening often enough to be the only reason for switching the issue tracker :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Bug 33169] KIndly update the date feature
On 2018-06-28, Stefan Bodewig wrote: > The ASF installations allow everybody to create accounts and everybody > to create new issues. This is a deliberate choice and is the same for > JIRA and Bugzilla - and is the best choice for an open source project > IMHO. > I'm not sure whether JIRA allows arbitrary users to modify existing > issues ither people have created. Of course you want everybody to be > able to comment, not so sure about the issue's title. https://www.youtube.com/watch?v=MO_AVjSPuBw&list=PLq-odUc2x7i-1f8XW3aYwGRc7YoWcCIxA&index=19 around minute 18 Mark explains why our Bugzilla is configured the way it is. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
FileUtils.normalize/isLeadingPath have bitten me
Hi all
while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.
If you feed into it a path with more "../" segments than can be
travelled up, like
FileUtils.normalize("/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt")
it will realize it would go outside of the file system root and returns
a new File instance with the original path. I'm not sure what I had
expected (an exception maybe) but this is now what I had assumed, my
fault.
Then isLeadingPath calls normalize for both its arguments and ends up
seeing "/tmp/dest/" is a prefix of
"/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt"
and unzip allows the file to escape.
It seems to depend on the OS what it makes of the path, on Linux I
receive an exception but apparently Windows just swallows the excess ../
segments.
I'm not 100% sure how to fix this properly.
Is normalize doing the right thing? If so, we need to fix isLeadingPath
for example by simply always returning false if either normalized path
contains "../" segments (because that means the path cannot exist on
disk at all).
Or should the behavior of normalize change? This unit test snippet
assertEquals("will not go outside FS root (but will not throw an
exception either)",
new File(localize("/1/../../b")),
FILE_UTILS.normalize(localize("/1/../../b")));
makes me think we better leave it as is as it seems to be by design (and
I just have forgotten about it).
In either case, once we agree on the fix I propose to cut new releases
immediately.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileUtils.normalize/isLeadingPath have bitten me
I don't have enough background on the expectations of the normalize
method, so can't really say how it should behave. Plus, it gets used in
relatively larger number of places as compared to isLeadingPath, so not
too sure how it might impact other places if we do change its existing
semantics.
However, looking at the FileUtils#isLeadingPath(...) implementation, I
wonder why it even uses normalize. Given that the goal of that API (as
stated in the javadoc) is to figure out if one path leads the other, to
me that translates to being a check to see whether the "leading" param
to that method is a parent of the "path". I suppose that can be
implemented by using the java.io.File#getCanonicalFile() call on each of
the params and then doing a iterative getParent() call on the canonical
File returned for the "path" and seeing if it ends up leading to the
canonical File returned for "leading". The call to
java.io.File#getCanonicalFile() should take care of the ".", ".." and
even symbolic link reference resolutions (which I guess is a good
thing?). Do you think this has merits? Or is the expectation of the
isLeadingPath API solely based on the names of that passed files rather
than their actual resolved location on the filesystem? I haven't yet
tried it out myself to have a more clearer understanding of how it will
end up behaving in the context that we use this API.
-Jaikiran
On 28/06/18 7:17 PM, Stefan Bodewig wrote:
Hi all
while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.
If you feed into it a path with more "../" segments than can be
travelled up, like
FileUtils.normalize("/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt")
it will realize it would go outside of the file system root and returns
a new File instance with the original path. I'm not sure what I had
expected (an exception maybe) but this is now what I had assumed, my
fault.
Then isLeadingPath calls normalize for both its arguments and ends up
seeing "/tmp/dest/" is a prefix of
"/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt"
and unzip allows the file to escape.
It seems to depend on the OS what it makes of the path, on Linux I
receive an exception but apparently Windows just swallows the excess ../
segments.
I'm not 100% sure how to fix this properly.
Is normalize doing the right thing? If so, we need to fix isLeadingPath
for example by simply always returning false if either normalized path
contains "../" segments (because that means the path cannot exist on
disk at all).
Or should the behavior of normalize change? This unit test snippet
assertEquals("will not go outside FS root (but will not throw an exception
either)",
new File(localize("/1/../../b")),
FILE_UTILS.normalize(localize("/1/../../b")));
makes me think we better leave it as is as it seems to be by design (and
I just have forgotten about it).
In either case, once we agree on the fix I propose to cut new releases
immediately.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileUtils.normalize/isLeadingPath have bitten me
On 2018-06-28, Jaikiran Pai wrote:
> However, looking at the FileUtils#isLeadingPath(...) implementation, I
> wonder why it even uses normalize. Given that the goal of that API (as
> stated in the javadoc) is to figure out if one path leads the other,
> to me that translates to being a check to see whether the "leading"
> param to that method is a parent of the "path". I suppose that can be
> implemented by using the java.io.File#getCanonicalFile() call on each
> of the params and then doing a iterative getParent() call on the
> canonical File returned for the "path" and seeing if it ends up
> leading to the canonical File returned for "leading". The call to
> java.io.File#getCanonicalFile() should take care of the ".", ".." and
> even symbolic link reference resolutions (which I guess is a good
> thing?).
I think I have written that method long ago so I should be able to
answer that. Unfortunately I'm not.
In may cases we did not want to resolve canonical paths. I think the
expectation is that for
/dir
/dir2
/dir3
link -> /dir/dir2
isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
not do if links have been resolved.
> Do you think this has merits? Or is the expectation of the
> isLeadingPath API solely based on the names of that passed files
> rather than their actual resolved location on the filesystem?
Yes, I think so.
> I haven't yet tried it out myself to have a more clearer understanding
> of how it will end up behaving in the context that we use this API.
It is used in SymbolicLinkUtils in a way that might break if symbolic
links are resolved.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileUtils.normalize/isLeadingPath have bitten me
On 28/06/18 8:37 PM, Stefan Bodewig wrote:
On 2018-06-28, Jaikiran Pai wrote:
However, looking at the FileUtils#isLeadingPath(...) implementation, I
wonder why it even uses normalize. Given that the goal of that API (as
stated in the javadoc) is to figure out if one path leads the other,
to me that translates to being a check to see whether the "leading"
param to that method is a parent of the "path". I suppose that can be
implemented by using the java.io.File#getCanonicalFile() call on each
of the params and then doing a iterative getParent() call on the
canonical File returned for the "path" and seeing if it ends up
leading to the canonical File returned for "leading". The call to
java.io.File#getCanonicalFile() should take care of the ".", ".." and
even symbolic link reference resolutions (which I guess is a good
thing?).
I think I have written that method long ago so I should be able to
answer that. Unfortunately I'm not.
In may cases we did not want to resolve canonical paths. I think the
expectation is that for
/dir
/dir2
/dir3
link -> /dir/dir2
isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
not do if links have been resolved.
That's a good example and yes it would return false if we would change
it to use canonical paths.
Which then makes me wonder - in the context of this specific
untar/expand/unzip issue, should we probably be using a different custom
very specific logic (which relies on canonical files and getParent())
instead of a call to isLeadingPath()? I don't have an answer though and
I will have to sleep over this a bit to see if it has other implications
and if it does indeed solve the issue at hand.
-Jaikiran
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileUtils.normalize/isLeadingPath have bitten me
On 2018-06-28, Jaikiran Pai wrote:
> On 28/06/18 8:37 PM, Stefan Bodewig wrote:
>> /dir
>>/dir2
>>/dir3
>> link -> /dir/dir2
>> isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
>> not do if links have been resolved.
> That's a good example and yes it would return false if we would change
> it to use canonical paths.
> Which then makes me wonder - in the context of this specific
> untar/expand/unzip issue, should we probably be using a different
> custom very specific logic (which relies on canonical files and
> getParent()) instead of a call to isLeadingPath()?
Probably. I used isLeadingPath because it has been already there - and )
simply didn't realize it wouldn't do what I expected it to.
https://github.com/apache/commons-compress/blob/a080293da69f3fe3d11d5214432e1469ee195870/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L245
is how I implemented it in Commons Compress' example code.
> I don't have an answer though and I will have to sleep over this a bit
> to see if it has other implications and if it does indeed solve the
> issue at hand.
I appreciate this a lot, many thanks.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
AW: [Bug 33169] KIndly update the date feature
Thanks, will have a look tomorrow. Sounds like we should keep BZ as it is. Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:bode...@apache.org] > Gesendet: Donnerstag, 28. Juni 2018 13:27 > An: dev@ant.apache.org > Betreff: Re: [Bug 33169] KIndly update the date feature > > On 2018-06-28, Stefan Bodewig wrote: > > > The ASF installations allow everybody to create accounts and > everybody > > to create new issues. This is a deliberate choice and is the same for > > JIRA and Bugzilla - and is the best choice for an open source project > > IMHO. > > > I'm not sure whether JIRA allows arbitrary users to modify existing > > issues ither people have created. Of course you want everybody to be > > able to comment, not so sure about the issue's title. > > https://www.youtube.com/watch?v=MO_AVjSPuBw&list=PLq-odUc2x7i- > 1f8XW3aYwGRc7YoWcCIxA&index=19 > > around minute 18 Mark explains why our Bugzilla is configured the way > it is. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
