On Feb 11, 2010, at 2:10 AM, Jonas Sicking <[email protected]> wrote:
On Wed, Feb 10, 2010 at 4:59 PM, Marcos Caceres <[email protected]>
wrote:
I'm sooooooo totally for that. I want nothing more than to have
more
engagement and input from you guys. Our URI spec is in last
call and so
is
the access request spec. The specs are really small. Please
find a few
hours
and help us align if we haven't already. It's never too late to
comment
and
help us fix stuff if it's borked. We are doing the best we can
here,
and
certainly don't want to go against the web security model.
It's funny that you say that, because last I commented on a widget
spec was in relation to the signing spec. I then expressed
dislike for
the use of xml canonicalization and, IIRC, a few other non-trivial
aspects of the spec. But was told that the spec was too far
along and
it was too late to change :-)
That is correct. Many members working on widgets believed that
the use
cases
were met by XML digsig (even with it's reliance on xml
canonicalization)
and
I was led to believe that it is in fact implementable. I know of
one
implementation thus far, so the jury is still out. It's still too
early
for
me to say if it was a mistake to take XML digsig over JAR
signing. If it
proves a mistake (I.e., no one implements), then it's logical to
look for
alternatives. I won't claim to understand the xml canonicalization
issue,
but people I talk to still tell me it won't be a problem. You
want to add
some tests to the test suite?:)
I don't doubt that it's implementable. However I still think there
are
much simpler solutions that make things easier both for authors and
browser implementors. See for example the way that mozilla signs XPI
files.
I don't disagree with you on the implementation side (and Im happy
to hear
that you think it can be implemented - I'll keep my fingers
crossed). On the
author side, I honestly don't know how much of a difference it will
make.
I'm sure someone will create a dead easy click once packager for
widgets, if
they haven't done so already. But is there something inherently
wrong with
our current technological choice that would not allow that? (if
yes, please
send to public-webapps, which is where we discuss widgets ;))
Ah, the old "the tools will save us" argument ;)
Ooooh, snap!! walked straight into that one :D
Yes, tools can certainly help. But that doesn't remove from the fact
that something that's simpler to author would be simpler for authors.
It's crypto: by definition, its really complicated; I don't know how
much easier one could make it. And reading https://developer.mozilla.org/en/Signing_a_XPI
I can see Mozilla's solution is far from easy to use. I was
expecting point and click, but I see a lot of scary (for me) command
line stuff. One even need a special zip tool because of the whole META/
inf thing?
What about situations when you want to dynamically generate widgets,
say using PHP?
What about it? Won't a simple command line tool work? You could have a
GUI version and a command line version. Like Zip.
Or if you don't speak the language(s) the tool is
localized to.
I don't understand this one? I guess as above.
Or if a web-based tool happens to be down because of
server upgrades?
I'm sorry, but i'm not really following as to what this has to do with
our choice to use XML DigSig as the sig format? Despite my silly tools
will save us mishap, my original question is still: is XML digsig
limited in some way that all the above command/GUI/web interfaces
could not be built on it (if they haven't already)? And what are the
advantages of XPI signing over the current model? Is it the
availability of tools to make sigs what makes it better or is it that
the sig format simpler? I can't see it being too much simpler from an
authors perspective. And once you implement it and get it running,
won't the XML cononicalization problems go away?
