On Thu, Dec 19, 2019 at 8:43 AM Antoine Pitrou wrote:
>
> Security is a concern for us and we welcome any reports. That said,
> Arrow is primarily concerned about efficiency (memory and processing
> efficiency), which implies that implicit checks cannot often be
> comprehensive.
>
Thank you for
Hi Adam,
Le 18/12/2019 à 20:00, Adam Hooper a écrit :
> Thank you for the responses, Wes and Antoine. I've sent to private@ and
> then filed https://issues.apache.org/jira/browse/ARROW-7435
>
> @Antoine I'm glad to hear the IPC layer is a security boundary. Could you
> please clarify what that
Thank you for the responses, Wes and Antoine. I've sent to private@ and
then filed https://issues.apache.org/jira/browse/ARROW-7435
@Antoine I'm glad to hear the IPC layer is a security boundary. Could you
please clarify what that means exactly? Do you mean (please check all that
apply):
1. Arrow
Hi Adam,
The validation was significantly enhanced in git master. In particular,
Array::ValidateFull() will validate data more or less extensively. I
wouldn't be surprised if not everything is validated, though. Feel free
to open JIRA tickets about missing validation checks.
However, if you a
hi Adam,
Can you please send the security issue to priv...@arrow.apache.org
(this is a moderated non-public list) and we can discuss there.
Thanks,
Wes
On Wed, Dec 18, 2019 at 10:43 AM Adam Hooper wrote:
>
> My project parses Arrow files produced by untrusted code.
>
> It looks to me like the "
My project parses Arrow files produced by untrusted code.
It looks to me like the "validate" function should help me avoid undefined
behavior given an invalid Arrow file. I found a bug in the function: even
after validation, an invalid Arrow file can trigger undefined behavior.
Is security a goal
