This page is part of the web mail archives of SRFI 84 from before July 7th, 2015. The new archives for SRFI 84 contain all messages, not just those from before July 7th, 2015.
On 1/27/06, Thomas Lord <lord@xxxxxxx> wrote: > > Well, really, the question comes down to "what are these names > for"? This is indeed the question. With respect to Zooko's Triangle, human-readable and decentralized seems to be the natural choice - at least that's what other module systems use. Let's consider what it would mean to have secure module names. There are, as the triangle indicates, two ways to handle this: decentralized, in which case the name itself is a digital signature proving the name belongs to a specific entity, or centralized, in which case you have a central trusted authority somewhere (such as at schemers.org) which maps names to entities (and vice versa). At first sight, the digital-signature naming of modules such as "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" is just silly. No one would write code like that, you'd always be looking at documentation and web pages for module names and cutting and pasting them. The notion of petnames (or similary some sort of project-wide lexically scoped aliases) is interesting, and possibly brings this back into consideration. There are a number of drawbacks, however. The first is the need for tool support, which we don't have yet and would take time to spread to all the different tools and implementations in use. The tools also wouldn't necessarily work in all situations, and may not play with other tool-chains and idioms - if I grep through code for a module I'd need to grep by the unwieldy signature, not my petname. Furthermore, communication is hampered when people may be using different names. Programmers wouldn't necessarily know if someone else's "html" module refers to Bob's HTML library or Alice's. Collaboration, education and presentations suffer. For a centralized naming authority, we'd setup some sort of registration system at a server like schemers.org, and delegate module namespaces to separate "entities," either organizations or individual authors, presumably identified uniquely by a public key. This is complicated, rigid and doesn't scale well. Rather than establish our own authority we could try to leverage an existing one, as Java does. com.microsoft.foo.bar is reserved for the owner of the microsoft.com DNS name. This may not be the most suitable level of entity for an authorization system. The example above could either refer to the foo.bar module of microsoft.com, or the bar module of foo.microsoft.com, which for Microsoft Corporation may not be such a problem, but for other hosts that conflict may be unacceptable. The naming is also not actually enforced by any of the Java tools - nothing is stopping me from distributing my own com.microsoft modules. All this, of course, has nothing to do with the security of the code itself. It just provides a module-name<->entity mapping. In and of itself, it doesn't even guarantee that the owner of the module name wrote the code that it's attached to. If using a DNS-based authority you could restrict it so that a com.microsoft module can only be run or installed if being accessed from a microsoft.com server. Alternately if using a schemers.org key-server you could require that the module code itself be signed by the same entity as that owning the module name. The question arises, since for any security considerations at all we're going to need to authenticate the entire module anyway, does the _name_ of the module itself need to be authenticated? As you say, "Does it really matter?" Imagine web browsers can launch Scheme applets, similar to Java applets but done right. Web browsers access a page with an <applet language="r6rs" ...> tag, the code is downloaded and signature verified, and a dialog pops up: Applet Name: XXXX Author: Acme.com (optionally shown as petname or with other trust or past applet use info) Desired Capabilities: (with big flashing warning signs because it's asking for a lot, or possibly just a summary "This applet can do anything to your computer, run at your own risk!") * local file access * network access * eval X Don't ask again when running this applet - Don't ask again when running modules from Acme.com At first glance the XXXX name of the applet (module) itself is meaningless. "Don't ask again" only works on the signature of the code itself and the entity, not the name. Now consider that, unlike Java, we actually write reusable code, and share modules with third parties. So Acme.com may import Bob's List Library. The page could tell you to download and install such and such a library, or for more automatic use refer to central or distributed repositories of known code, or even link directly to .jar's or .scm's in the <applet> tag itself. When the module is run, the dialog confirmation will show for all new modules. Bob's List Library shows as requiring no capabilities (it just uses CONS, CAR and CDR), or possibly even is loaded without confirmation because of this. It's at this stage where there's a possibility of attack based on module names, if the module names are the only means the modules have of referring to one another. If Acme.com uses Bob's Library, it will point directly to safe URL's or repositories, and even if it just puts a notice "you need to install Bob's List Library version >= 2.1," with no link, then when people will Google for said library and come up with the correct link (without really ingenious and well-timed SEO). However, the villain Charlie comes along and puts on his own site a link to an applet saying "hey, check out Acme.com's new domestic animal hunter game!" You've heard of the game and decide to try it out, the applet verifies the game and the author Acme.com, along with some other incidental modules such as "Bob's List Library" which verifies and requires no capabilities so you click OK. However, Bob's List Library was actually written and verified by Charlie's key, and although it itself has no capabilities, it has been cleverly designed to return bad data back to the calling Acme.com module in certain situations such that security is compromised (perhaps URI's are manipulated in list representation, and when the result is '(http acme.com login.cgi) it instead arranges for the login info to be sent to Charlie's server). So even with full digital signatures and an elborate trust system and petnames, code can be compromised if modules refer to each other by name and those names aren't secure. There are a number of ways to resolve this, the first and most obvious of which in the above example is for the <applet> tag itself to be signed by the same entity as the applet, or to include signatures for the modules it uses. Alternately you could de-emphasize the fact that the List Library uses no capabilities, and prominently give a dialog of all authors with all capabilities the collection of modules accessed by the applet - trusting Charlie's code in that situation is the same as installing unknown software from Charlie. And we can, of course, simplify things by deferring to other authorities. If module names are based on domain names, then we could use Yahoo Domain-Keys as the signature method. In this case when you verify (schemers.org srfi 1) against the public key stored in the DNS TXT entry for _domainkey.schemers.org, you simultaneously know that both the code _and_ the name are valid. This is very close to having all three points of the triangle. -- Alex