To finish up this thread, the rustsec advisory has been updated:
https://github.com/rustsec/advisory-db/pull/1131
On Tue, Nov 30, 2021 at 5:10 PM Andrew Lamb wrote:
> Well, I finally have a PR[1] that adds full ArrayData validation ready
> for review Any thoughts or review comments would be mo
Well, I finally have a PR[1] that adds full ArrayData validation ready for
review Any thoughts or review comments would be most helpful.
Thank you,
Andrew
[1] https://github.com/apache/arrow-rs/pull/921
On Fri, Oct 29, 2021 at 6:23 AM Andrew Lamb wrote:
> There is more discussion about the R
There is more discussion about the RUSTSEC process here:
https://github.com/rustsec/advisory-db/issues/1092
On Wed, Oct 6, 2021 at 10:52 AM Andrew Lamb wrote:
> I have incorporated feedback into a proposal [1] of how to handle
> validation of arguments to ArrayData::new, and would appreciate fur
I have incorporated feedback into a proposal [1] of how to handle
validation of arguments to ArrayData::new, and would appreciate further
review
[1] https://github.com/apache/arrow-rs/issues/817
On Fri, Oct 1, 2021 at 6:44 AM Andrew Lamb wrote:
> Thank you Antoine,
>
> The C++ validation routin
Thank you Antoine,
The C++ validation routine is super helpful, especially with respect to
validating nested structures. I will follow its lead
Andrew
On Fri, Oct 1, 2021 at 3:25 AM Antoine Pitrou wrote:
>
> In C++ we have dedicated validation routines that can be used against
> untrusted inpu
In C++ we have dedicated validation routines that can be used against
untrusted input. (*) We also have fuzzing set up using OSS-Fuzz to
validate that invalid input cannot crash the IPC reader.
(*)
https://github.com/apache/arrow/blob/master/cpp/src/arrow/array/validate.h
Le 01/10/2021
I have created a WIP PR for initial feedback on the approach of validating
ArrayData upon creation[1]. If there are no objections to the approach I
will complete the implementation over the next few days
The approach that Sergey describes of `get` and `unsafe get_unchecked`
sounds like a good one
I believe feature flags are not the right choice here. The problem is that
feature flags are toggled globally, so the behavior of your crate can be
affected by the behavior of some other crate that toggles the feature.
A better approach is to provide two methods, one safe and the other unsafe,
see
In the past I was dealing with something similar. My experience was when
data was accepted at the edge, the cost of validating that the first offset
is zero, the last is within the data bounds and that all others are equal
or increasing was a reasonable overhead associated with validating offsets
f
I understand the need to avoid sacrificing performance as much as possible.
I have begun looking into adding validation into ArrayData::new as you
suggest.
I am making progress, but haven't fully figured out the nested types yet.
Hope to have a PR up in the next day or two.
Should we come up with
Most of these issues seem to originate from creating arrays from ArrayData.
While we could validate buffers in the XArray::from implementations, that
would have some performance overhead and also some edge cases for nested
data. Thinking about List>>, we recursively would need to
validate and know
Dear Rust Developers,
As a heads up, several pre-existing security tickets filed against arrow-rs
have been added[1][2] to the RUSTSEC database[1][2] a few hours ago. The
author says he plans to file additional RUSTSEC entries for the other
security tickets [3].
The criteria used for adding the a
12 matches
Mail list logo
