lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 09:44, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:
> 
>> Yes, for most cases we would probably not need root access at activation time, but for those cases you just listed, we would.  We could do a pass over the bom to determine if root access is needed or not.  The UI for handling such a case is non-trivial.  Do we prompt once for the entire run of the process or escalate permissions for each port we encounter and then drop them again?  If 8 ports are being installed and 4 require root, that's not a good user experience to prompt for password 4 times.
> 
> I think it'd be up to the port to indicate if it requires root privileges during the destroot. This is (implicitly) what happens with ports that create a new user or group; there's a phase that requires root (configure, I think).

> How's that handled at the UI level? I'm guessing that the phase will simply fail for the port(s) that don't have the appropriate privileges.


My point is not about the failure case but the working case.  

Ideally, the user would be able to do 'port -v -s install <port that doesn't require root but may have 2-3 dependencies that do>'.

The secure thing to do is not escalate until we need to, prompt, do our thing, then throw away the privs when done.  The problem with that is that we'd ask for credentials 2-3 times during the install and only when we need them.

The less secure thing to do is just ask for credentials up front if anything will need root access and then just promote/demote as needed.

The latter is a better user experience, and perhaps this can be the default but configurable for those that want more security.

>>> I understand that the certificate catching is coupled to the file's inode (whatever that is under HFS+), and the new copy indeed had a new inode. And yet another inode after signing it.
>> 
>> If you can reproduce this, please let me know and file a radar with details and let me know the number, so I can followup internally on it.  I haven't seen such cases.  The only issue I'm aware of is with overwriting an existing file (eg: using cp instead of mv).
> 
> To make this reproducible I'd probably be looking at the following sequence?
> 1) copy a binary from some original and ad-hoc sign it
> 2) delete it
> 3) copy the original once more and sign it with another certificate
> 
> Correct me if I'm wrong, but I think that's what a `port -n upgrade --force` boils down to if signing is done in the post-activate, no?
> Is there any reason to expect that the certificate used in 3) must be a new one not yet used to sign other executables?
> 
>> iOS was never branded as UNIX.  It is UNIX-like, but it was never UNIX.
> 
> AFAIK it is or used to be based on OS X, evidently without the userland but with a comparable kernel. Was that just a shortcut way of thinking of things?

iOS has the same core os macOS.  Much of everything below the UI layer is shared between the two platforms, but there are subtle differences, similar to  how tvOS and watchOS are forked from iOS.

Even though iOS shares much of the same codebase as macOS, it is not UNIX.  Apple has never certified iOS as UNIX.


>> I've got an internal 1TB SSD and it is more than enough for most of my needs.  I mainly use USB for thumbsticks and my camera.  In such cases, the throughput is bottlenecked on the attached device, not the bus.
>> 
>> That being said, my server machine is a 2012 MacMini, and I've got a DroboMini and a LaCie RAID attached to it via thunderbolt, and the throughput and latency are more than adequate for my demanding needs.
> 
> Thunderbolt external disks and 1TB SSDs are simply out of my budget.
> 
>> For folks like you and me, it might be a minor concern being limited to 1TB, but we can certainly use an external SSD or an SDXC to increase storage as needed in the future.
> 
> I see it as more than a minor concern. Not because I expect I'll ever need more than 1TB internal space, but I would certainly not feel comfortable when I know I cannot replace something that can fail that easily and unpredictable as an SSD (or HDD for that matter). I don't recall but it's quite likely too that I replaced the HDD in my current MBP with a Hitachi as soon as I received the machine.

FWIW, HDDs are much more flakey than SSDs.  I've had to replace countless HDDs in my life, but I've yet to see one of my SSDs reach the end of their lives.

> My only experience to date with SSDs was as an external. Connected over FW800 (the fastest bus I had at the time) showed 0 gain over a good HDD ... and the whole thing died catastrophically after not even 4 months.

Then you definitely weren't using a good SSD. =/

> FWIW, that Clevo notebook I mentioned has an internal 2.5" disk (came with an SSHD) but even at its price point it has a fashionable slot to add an SSD. That's the kind of approach I like: adding expansion options instead of removing them.

Well, you can certainly upgrade the storage after purchase if you want (cf https://eshop.macsales.com/shop/ssd/owc/macbook-pro-retina-display/2013-2014-2015)

There's also an SDXC port there.  You can get a micro SDXC card and one of the many flush-insert adaptors

https://www.amazon.com/MiniDrive-microSD-Adaptor-MacBook-Retina/dp/B00AL1385C
https://www.amazon.com/HyperDrive-microSD-Adapter-MacBook-Retina/dp/B00PUY58M6
etc

> 
> R.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160911/c06b90e4/attachment-0001.p7s>