As far as I understand, ad-hoc codesigning is not actually really meant to
protect a file on disk because you can just ad-hoc sign again when you modify
the file; instead it simplifies some of Apple’s own code because it removes the
special case of a binary that doesn’t have a signature (which
On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote:
>
> To me it seems unrealistic for Apple to suggest that an infinite number of
> open source projects, many of whose developers have never seen a Mac, should
> now add code to their build systems to codesign things on macOS. Apple made a
>
>
> I've read that number of duplicates is one of the ways they determine
> issue priority internally.
>
I can confirm that this is indeed supposed to be the case. Our Apple
engineering liaison at the university where I used to work as a sysadmin
frequently repeated this during our Apple
On 2020-9-23 05:33 , Ryan Schmidt wrote:
>
> Send feedback through the Feedback Assistant app.
Yes, everyone with any issues with Apple preview software should do this
early and often. I've read that number of duplicates is one of the ways
they determine issue priority internally.
- Josh
On Sep 22, 2020, at 14:52, Ken Cunningham wrote:
> On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote:
>>
>> I hope that Apple fixes their toolchain to work without such intervention.
>
> I believe this may ultimately come under the category of "intended
> behaviour".
To me it seems
On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote:
>
> I hope that Apple fixes their toolchain to work without such intervention.
>
I believe this may ultimately come under the category of "intended behaviour".
I can understand why they would want these changes to invalidate the signature.
I
On Sep 22, 2020, at 14:19, Michael Dickens wrote:
> I have macOS 11.0beta7 installed : check!
>
> Compare / contrast ARM Mac versus MacBook Pro 16 : check!
>
> I have Xcode 12.2 beta installed : check!
>
> I've removed "/Library/Developer/CommandLineTools" : check!
>
> I hope that Apple
I have macOS 11.0beta7 installed : check!
Compare / contrast ARM Mac versus MacBook Pro 16 : check!
I have Xcode 12.2 beta installed : check!
I've removed "/Library/Developer/CommandLineTools" : check!
I hope that Apple fixes their toolchain to work without such intervention :
check!
Do you
On Sep 22, 2020, at 13:29, Michael Dickens wrote:
> % codesign -v - --ignore-resources
> /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8:
> invalid signature (code or signature have been
There has been some discussion about the recent change Apple made for macOS
11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had
some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As
pointed out, a better venue for discussion would be these lists.
On Sep 22, 2020, at 13:28, Vincent Habchi wrote:
>> (xz is 85% of bz2 size)
>> (xz is 70% of bz2 size)
>> (xz is 57% of bz2 size)
>>
>> So I think we could save ourselves and our mirror providers, CDN, and users
>> some disk space and bandwidth by switching to xz. bz2 was the best available
> (xz is 85% of bz2 size)
> (xz is 70% of bz2 size)
> (xz is 57% of bz2 size)
>
> So I think we could save ourselves and our mirror providers, CDN, and users
> some disk space and bandwidth by switching to xz. bz2 was the best available
> built-in compression on Mac OS X 10.6 when we started
On Sep 22, 2020, at 07:58, Vincent wrote:
>> It would be nice if we could easily switch our precompiled archives from
>> bzip2-compressed tarballs (tbz2) to better compression methods as they
>> become available. For example, xz-compressed tarballs (txz) would be better
>> today. OS X 10.9
It would be nice if we could easily switch our precompiled archives from
bzip2-compressed tarballs (tbz2) to better compression methods as they become
available. For example, xz-compressed tarballs (txz) would be better today. OS
X 10.9 Mavericks and later has built-in support for xz
14 matches
Mail list logo
