Author culler
Recipients Aivar.Annamaa, culler, eric.smith, ned.deily, ronaldoussoren
Date 2020-12-28.16:41:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1609173712.49.0.0909883355047.issue42068@roundup.psfhosted.org>
In-reply-to
Content
Hi Ned, I have a comment about the code signing issues that would arise if the Tcl and Tk frameworks were embedded as actual subframeworks inside the Python.framework, and a user later replaced those with newer versions. The answer is that no new issues arise.  The current Python.framework fails codesign verification as soon as a single new package is installed with pip (even upgrading pip itself).  The codesign command detects the new files and exits with non-zero status if called with --verify.  In verbose mode it will list all of the files that were added.

This does not prevent python from working.  So it should just be acknowledged that python's codesigning is used purely to make installation simpler and that no attempt is currently being made to ensure that an installed python framework continues to pass codesign verification.  As a consequence, my proposal in this ticket would raise no new codesigning issues, but it would allow users to much more easily upgrade the Tcl and Tk embedded in /Library/Frameworks/Python.framework versions.  It would also simplify the recipe for building Tcl and Tk in the buildscript.

While the python framework may be viewed as a black box, in fact it is not a black box at all.  It can be changed at will either by python itself or by a user.  Making its structure clearer and cleaner could only be an improvement.
History
Date User Action Args
2020-12-28 16:41:52cullersetrecipients: + culler, ronaldoussoren, eric.smith, ned.deily, Aivar.Annamaa
2020-12-28 16:41:52cullersetmessageid: <1609173712.49.0.0909883355047.issue42068@roundup.psfhosted.org>
2020-12-28 16:41:52cullerlinkissue42068 messages
2020-12-28 16:41:52cullercreate