magibney commented on PR #12096:
URL: https://github.com/apache/lucene/pull/12096#issuecomment-1399322839

   I think reproducible builds would be an great goal! (and second Jan's 
suggestion of proposing on dev list).
   
   Paradoxically, further consideration of the issues that "reproducible 
builds" seek to address has reinforced some nagging doubts I had about removing 
the userid from the manifest.
   
   It's about trust. We don't have `@author` tags etc. in code, but the project 
does have usernames all over it -- in the form author/committer fields of 
commits. The process of preparing a release is mechanical, but it definitely 
requires trust in the RM (`>=` trust required for a commit). And I realize that 
the gpg signing of release artifacts fills this role (and in a more substantial 
way), so username in MANIFEST.MF is arguably redundant. But I think 
broadcasting the identity of the user who produced the artifact makes sense. 
When the same user _signs_ the artifacts, there's an implicit endorsement of 
the build user/agent as recorded in the MANIFEST.MF.
   
   I'm not going to make an issue of it one way or another; and I'm still happy 
to merge this PR. But tbh my personal inclination would be to leave the userid 
in the manifest. It's trust and provenance for the "last mile" that bridges the 
gap between source code and the artifacts that most users will actually 
interact with; and even if in a sense it's redundant, declaring it explicitly 
as part of the build artifact strikes me as appropriate.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to