Conversation
github-actions
bot
added
parquet
|
FYI @scovich @Jefffrey @etseidl @tustvold @jhorstmann, and @crepererum who may be interested in commenting on this policy |
scovich
left a comment
scovich
left a comment
There was a problem hiding this comment.
The doc and associated link sprinkling seem very reasonable and welcome, but I don't think I understand how this will "reduce the flow" of "a deluge of low quality bug reports masquerading as security problems" ?
Or does it just make it easier to summarily close them because they don't follow the official guidelines?
| - Reading data from untrusted sources (e.g., over a network or from a file) requires explicit validation. | ||
| - Failure to validate untrusted data before use may lead to security issues. This implementation provides APIs to validate Arrow data. For example, [`ArrayData::validate_full`] can be used to ensure that data conforms to the Arrow specification. | ||
|
|
||
| ## Rust Safety and Undefined Behavior |
There was a problem hiding this comment.
I think we should define what exploitable means, as it is so important to this section.
Perhaps inline whatever gets merged from https://github.com/apache/arrow/pull/49761/changes or at least link to it
❤️
Yes, basically having this documented means that upstream filters (aka the apache security team) can point to these guidelines if they get reports that are bugs. At the moment in Arrow sometimes it is not clear which crash is a security issue and which is just a bug
Yes that is an excellent idea and I will do so |
| [`simdutf8`]: https://crates.io/crates/simdutf8 | ||
| [parquet variant]: https://github.com/apache/parquet-format/blob/master/VariantEncoding.md | ||
|
|
||
| ## Parquet Feature Status |
There was a problem hiding this comment.
Why is this section removed?
There was a problem hiding this comment.
🤦 -- not sure -- will revert
Co-authored-by: Ed Seidl <etseidl@users.noreply.github.com>
4 participants
Which issue does this PR close?
Rationale for this change
Other arrow subprojects (C++ in particular) has been beset recently by a deluge of low quality bug reports masquerading as security problems.
To reduce this flow and make it easier to direct people to the appropriate bug vs feature venue, we should document our security posture better
What changes are included in this PR?
Are these changes tested?
By CI
Are there any user-facing changes?
yes, new policyt