<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 19, 2014 at 11:36 PM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="">So for MacOS-style applications, the static vs. dynamic issue is as much or as little of an issue as you choose to make it. Any libraries placed in the appropriate directories under the Foo.app directory are "morally statically linked": The program will always choose them first, ahead of anything else on the system. System libraries aren't normally carried along with applications, but nothing (as far as I know) says they can't be.<br>
</div><div><br></div><div>So all this concern is related to programs built and run the old-fashioned way, as simple executable files that dynamically load from the system library path. Applications built as .app files can easily carry along as little or as much of their environment as appropriate. For code that relies on OpenSSL, carrying along a private copy that you code was built against seems like a fine idea. But you do have to package it all up in MacOS style - something your typical OSS projects, supporting multiple platforms, are unlikely to want to bother with.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div><div> -- Jerry</div></div><div> </div></font></span></div><br>_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br></blockquote></div><br></div><div class="gmail_extra">This is almost the right way to ship and update applications. Every application is tested with a fixed set of shared libraries, and that is the set that likely will be most stable over time. Updating shared-libraries underneath an application is not just insecure, it's a great way to introduce bugs.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The right way to do applications is much like this, where we also run each application in it's own security jail (as Android does - I don't personally bother reading anything from an organization as evil as Apple, so I don't know what they do).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In addition, to save on space, identical binaries should only exist on disk once. This can be done trivially with hard links. Finally, there should be a way to do "critical" updates of libraries. For example, all the apps linking to OpenSSL, should be updated after the Heartbleed discovery. The application authors should mostly lock down the libraries they link to, but the distro maintainer should be able to override those choices in critical situations.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I can't even begin to explain here how many benefits such a system would have for GNU/Linux. GNU/Linux is losing the OS war for the desktop. The way GNU/Linux is built and distributed requires insane testing and maintenance, which is why you can't just publish an app today, and access it in Debian Stable tomorrow. GNU/Linux is basically designed to break, and the way we work around that stifles innovation. GNU/Linux needs an Android-inspired App delivery system.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Bill</div></div>