search

adobe-type-tools / afdko

Adobe Font Development Kit for OpenType
https://adobe-type-tools.github.io/afdko/
Other
1.06k stars 167 forks source link

[change] add 'noaccess' directive to t1write_flexothers.h for consistency with source document #1659

Closed jayaddison closed 1 year ago

jayaddison commented 1 year ago

While reading Debian bug 1029555 I decided to compare the contents of the Type1 programs listed in the T1 Spec to the code in this repository. Debian attempts to attribute copyright fairly thoroughly, so as a contributor there I'd like to check the details. The good news is that it's mostly identical.

However: comparing the program listings in t1write_hintothers.h and t1write_flexothers.h to the versions published in the "Adobe Type 1 Font Format" manual, I noticed some insignificant differences (spacing, comment formatting, and the representation -- but not value -- of some floating point numbers), but in particular there is one difference that seems like it could be more actionable:

The original program listings end with a noaccess directive that appears to be missing from the versions in this repository, and it seems like it might be a good idea to include that in order to make the open source versions more-equivalent to the original, and to reduce unnecessary access to the annotated objects.

It's a nitpick but perhaps a worthwhile and easy one to address. I'll provide a corresponding pull request for discussion soon.

josh-hadley commented 1 year ago

Hi @jayaddison, thanks for your note. There is indeed a difference between the T1 spec examples vs what AFDKO emits. This difference is not a problem. It's been like this since the AFDKO code was made open source. There is no need to make a pull request to change this.

jayaddison commented 1 year ago

Thanks, @josh-hadley. One of the perspectives I'm viewing from is that of someone who discovers the example code in one of their fonts, and wants to be confident that the snippet is indeed the same as the open source one. To that extent, it mostly is, but comfort levels would probably increase the more equivalent the snippets are.

The other viewpoint is one related to least-privilege requirements, where generally for stable and reliable systems it can make sense to (gradually) reduce no-longer-required read/write access to code and data. That in combination with the T1 spec paragraph related to PostScript interpreter integrity and the internaldict references made me wonder whether this code would be a good candidate for restoring the noaccess directive.

I did write to (and wait for a response from) a security contact at Adobe to check about the noaccess discrepancy before filing this, and any security implications due to that, and they've reassured me that they don't believe there's any security issue here - so I'm confident it's fine, but even so I felt it'd be worth considering.

Thanks again - and if this seems a bit verbose, it's partly because I'm writing for anyone else who may walk through some of the same investigation steps in future.

jayaddison commented 1 year ago

Although I did have a work-in-progress modification planned to open as a pull request, I think I am unlikely to make further progress on it in the near term.

The blocker / problem I ran into was that I wasn't sure how to update the test expectation files.