I've read https://infra.apache.org/crypto.html, and here are some thoughts

In https://github.com/pouchdb/pouchdb/blob/master/docs/asf.md?plain=1#L249-L255,
Jan notes:

> PouchDB does not directly include cryptography code, but makes use of 
> in-browser
TLS. A PouchDB plugin crypto-pouch exists that does record-level encryption, but
it is currently not part of the PouchDB code base. If md5 hashing is considered
cryptography, PouchDB, like CouchDB, makes use of that, just note that md5
hashing is not used for security relevant operations.

It definitely looks like the only current use of node's `crypto`
library is for hashing and generating random values:

```
$ git grep -Eo 'crypto\.\w+' | cut -d: -f2 | uniq
crypto.createHash
crypto.getRandomValues
```

>From the guidelines at https://infra.apache.org/crypto.html:

> Q. Do digest algorithms such as MD5 and SHA1 require notification?
> A. No.

---

However, the guidelines also state:

> PMCs considering...designing their products to use other software with 
> cryptographic functionality, should take the following steps...

pouchdb-adapter-http is explicitly written to work with HTTPS.  Does
this mean it's designed to use other software with cryptographic
functionality?  That would seem extreme.

---

https://infra.apache.org/crypto.html mostly talks about shipping
cyptographic source or object code, which pouchdb is not doing.

However, there are historic examples in the git repo where crypto code
*is* probably included:

* the selenium standalone .jar (first at
082c7da0b6b85649f9490ffb855c81c6cd20cf18)
* aes, diffie-hellman, des implementations (first at
eb7d421640d2ba7d6f36231bb0f434f68a49f8b5)

Maybe these require reporting?

An alternative might be to rewrite history to remove third-party
binaries and build artifacts.

I'm generally against rewriting history, but it would likely reduce
repo size significantly, as well as simplifying audit.

---

Alex

Reply via email to