Hi, It's been a while, but I've opened a PR to document the Avro security model on the website: https://github.com/apache/avro/pull/3403
The corresponding Jira ticket is https://issues.apache.org/jira/browse/AVRO-4145 Kind regards, Oscar On Tue, 20 May 2025 at 14:57, Oscar Westra van Holthe - Kind < opw...@apache.org> wrote: > Hi, > > Some recent developments had me thinking on security, and especially > vendor risks. One of my starting points is then what is common in open > source, as this is often a source of high quality stuff (and ... other > quality as well). As such, I also came across the Security page we have in > the Avro doc/ folder. > > Now the essence of that page is nice and clear: "Apache Avro project > shares the same security policy as the Apache Software Foundation" > > This means reporting issues, etc. However, there is nothing on our > security model. I.e., what can users of our library expect, and what should > they do themselves? > > To address this, I propose adding two headers and a few paragraphs, > resulting in something like: > > *Security Policy* > > Apache Avro project shares the same security policy as the Apache Software > Foundation. > > *Security Model* > > The Avro library implementations are designed to read and write any data > conforming > to a schema. Transport is outside the scope of the Avro library, so when > downstream > applications process sensitive data, it is their own responsibility to > ensure the > integrity and security of the data. > > Although the Avro library will not read or write data except as directed > to by > invoking it, avoiding leaking data into a side channel like log files is a > non-goal > security-wise for Avro. This means, for example, that you will need to > catch and > handle exceptions instead of simply writing them to a log file. > > Having said this, downstream applications can expect that Avro will not > read or > write data unless this is clear from the API, nor will we execute random > code. > Although schemas can define custom (implicit) conversions, and execute > foreign > code, this is always controllable by the downstream application. > > > What do you think can be improved? I'm quite new to this sort of > documentation, so any tips to improve this are most welcome! > > > Kind regards, > Oscar > > -- > > ✉️ Oscar Westra van Holthe - Kind <opw...@apache.org>🌐 > https://github.com/opwvhk/ > > > >
