[
https://issues.apache.org/jira/browse/SOLR-14695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168376#comment-17168376
]
Ishan Chattopadhyaya edited comment on SOLR-14695 at 7/31/20, 4:11 AM:
-----------------------------------------------------------------------
bq. SHA alone is normally only recommended to check that the download
succeeded, not to assert you got the authentic bits.
SHA512 is a cryptographic hash, it helps validate the jars. It isn't like MD5
etc., that are used only for file integrity. -Also, important to note that
those jars need to be present locally on the filesystem.-
bq. I assume you propose this as a temporary solution for shipping 1st party
packages as part of "fat distro", i.e. the distro tgz contains all pacakges. I
see the need until we have PGP validation.
The idea is that first party artifacts be trusted by default (using this
shipped trusted artifacts file), to defend against the possibility of any
committer's keys (those who have entry in KEYS file) being compromised.
However, if user is upgrading their first party packages, he/she will need to
get them from the hosted packages anyway, and need to trust RM GPG keys.
bq. I'm worried that we keep adding required files to SOLR_HOME here. We're
trying to get rid of the requirement for solr.xml and zoo.cfg, so users can
start Solr with a completely empty SOLR_HOME.
We can add this file to dist/ directory as well (where the repository.json
exists). We just need to make sure (by way of documentation) that users do not
edit the trusted-artifacts.json file, and it is meant only for first party
packages.
was (Author: ichattopadhyaya):
bq. SHA alone is normally only recommended to check that the download
succeeded, not to assert you got the authentic bits.
SHA512 is a cryptographic hash, it helps validate the jars. Also, important to
note that those jars need to be present locally on the filesystem.
bq. I assume you propose this as a temporary solution for shipping 1st party
packages as part of "fat distro", i.e. the distro tgz contains all pacakges. I
see the need until we have PGP validation.
The idea is that first party artifacts be trusted by default (using this
shipped trusted artifacts file), to defend against the possibility of any
committer's keys (those who have entry in KEYS file) being compromised.
However, if user is upgrading their first party packages, he/she will need to
get them from the hosted packages anyway, and need to trust RM GPG keys.
bq. I'm worried that we keep adding required files to SOLR_HOME here. We're
trying to get rid of the requirement for solr.xml and zoo.cfg, so users can
start Solr with a completely empty SOLR_HOME.
We can add this file to dist/ directory as well (where the repository.json
exists). We just need to make sure (by way of documentation) that users do not
edit the trusted-artifacts.json file, and it is meant only for first party
packages.
> Support loading of unsigned jars
> --------------------------------
>
> Key: SOLR-14695
> URL: https://issues.apache.org/jira/browse/SOLR-14695
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Package Manager, packages
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Major
>
> Solr distribution can keep a set of sha512 hashes of already trusted jars.
> This helps loading first party jars without signing.
> The file may look as follows and this is placed at
> {{<solr-home>/filestore/\_trusted_/artifacts.json}}
> {code:json}
> {
> "file-sha512" : {
> "dih-8.6.1.jar" :
> "d01b51de67ae1680a84a813983b1de3b592fc32f1a22b662fc9057da5953abd1b72476388ba342cad21671cd0b805503c78ab9075ff2f3951fdf75fa16981420"
> }
> }
> {code}
> * if the sha512 of a certain file is trusted, it does not have to be signed
> with any keys.
> * There is no API to create or modify this. The Solr build scripts create
> this file at build time and add this to the distro
> see the
> [document|https://docs.google.com/document/d/1n7gB2JAdZhlJKFrCd4Txcw4HDkdk7hlULyAZBS-wXrE/edit#]
> for more details
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
