When starting etoys for the very first time, a crypto key is generated. This takes about a minute on the laptop. It's particularily frustrating because the counter does not stop at 100% but goes well beyond, everyone would think it does not finish at all.
Could we postpone key generation to the time it is actually needed, rather than first start? I guess the reason to do it this way is because of the sandbox? Can we do something to avoid that delay? Do we need the key at all?
- Bert -
We certainly don't need the key for this build ...
Cheers,
Alan
----------
At 06:13 AM 10/19/2006, Bert Freudenberg wrote:
When starting etoys for the very first time, a crypto key is generated. This takes about a minute on the laptop. It's particularily frustrating because the counter does not stop at 100% but goes well beyond, everyone would think it does not finish at all.
Could we postpone key generation to the time it is actually needed, rather than first start? I guess the reason to do it this way is because of the sandbox? Can we do something to avoid that delay? Do we need the key at all?
- Bert -
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
I'm not sure if project saving will break. Can someone try, and publish a CS turning of the pref if it works?
- Bert -
Am 19.10.2006 um 15:41 schrieb Alan Kay:
We certainly don't need the key for this build ...
Cheers,
Alan
At 06:13 AM 10/19/2006, Bert Freudenberg wrote:
When starting etoys for the very first time, a crypto key is generated. This takes about a minute on the laptop. It's particularily frustrating because the counter does not stop at 100% but goes well beyond, everyone would think it does not finish at all.
Could we postpone key generation to the time it is actually needed, rather than first start? I guess the reason to do it this way is because of the sandbox? Can we do something to avoid that delay? Do we need the key at all?
- Bert -
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Whatever else we do about this, that progress-bar which reports runaway figures such as "580% completed" has to be tamed; even it we retain its nowadays-faulty heuristic for estimating how long the key- generation *should* take, we obviously need to cap the completion percentage we report at 99%... (I'll do that.)
Anyway... it appears that disabling the #automaticKeyGeneration preference keeps the key-generation from happening at start-up, yet still allows publishing and loading projects, and still uses MySqueak as the default directory. Maybe that's all that's needed.
Or perhaps, for this build, would it make sense simply to include a pre-built squeak.keys file alongside the image, and not otherwise tamper with the security settings?
Cheers,
-- Scott
On Oct 19, 2006, at 9:02 AM, Yoshiki Ohshima wrote:
Bert,
I'm not sure if project saving will break. Can someone try, and publish a CS turning of the pref if it works?
I don't mind to take on this, but Scott, what do you think?
-- Yoshiki
We certainly don't need the key for this build ...
Cheers,
Alan
From: bert@freudenbergs.de Subject: Re: [Etoys] Key generation Date: October 19, 2006 6:54:39 AM PDT To: etoys@laptop.org
At 06:13 AM 10/19/2006, Bert Freudenberg wrote:
When starting etoys for the very first time, a crypto key is generated. This takes about a minute on the laptop. It's particularily frustrating because the counter does not stop at 100% but goes well beyond, everyone would think it does not finish at all.
Could we postpone key generation to the time it is actually needed, rather than first start? I guess the reason to do it this way is because of the sandbox? Can we do something to avoid that delay? Do we need the key at all?
- Bert -
Etoys mailing list
Scott,
Whatever else we do about this, that progress-bar which reports runaway figures such as "580% completed" has to be tamed; even it we retain its nowadays-faulty heuristic for estimating how long the key- generation *should* take, we obviously need to cap the completion percentage we report at 99%... (I'll do that.)
Yes. (It's noted in "to do after Oct 23rd.")
Anyway... it appears that disabling the #automaticKeyGeneration preference keeps the key-generation from happening at start-up, yet still allows publishing and loading projects, and still uses MySqueak as the default directory. Maybe that's all that's needed.
I would think so. Did you try to load a project published from an image in a directory into another image in another directory?
Or perhaps, for this build, would it make sense simply to include a pre-built squeak.keys file alongside the image, and not otherwise tamper with the security settings?
Yeah, I thought about this but I think it adds unnecessary complication.
-- Yoshiki
I'll ask Andreas about this later today.
Meanwhile, perhaps Bert could speak with Michael about it as well.
Couldn't hurt to have the advice of the world's two leading authorities on this subject...
Cheers,
-- Scott
On Oct 19, 2006, at 1:32 PM, Yoshiki Ohshima wrote:
Anyway... it appears that disabling the #automaticKeyGeneration preference keeps the key-generation from happening at start-up, yet still allows publishing and loading projects, and still uses MySqueak as the default directory. Maybe that's all that's needed.
I would think so. Did you try to load a project published from an image in a directory into another image in another directory?
Or perhaps, for this build, would it make sense simply to include a pre-built squeak.keys file alongside the image, and not otherwise tamper with the security settings?
Yeah, I thought about this but I think it adds unnecessary complication.
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Well, Michael is a bit unsure ;-)
The key might still be in use for signing projects when publishing. If you download a project that was signed with your own key, the sandbox is not switched on. So having a single key for all users would be bad, because everyone would be trusted. Having no key means everyone would be distrusted, which is what we want I think.
We would have to test if projects are still interchangeable between machines with and without key (remember to remove the key from the secure directory). It might be that some file offset changes if the key is taken out.
- Bert -
Am 20.10.2006 um 14:05 schrieb Scott Wallace:
I'll ask Andreas about this later today.
Meanwhile, perhaps Bert could speak with Michael about it as well.
Couldn't hurt to have the advice of the world's two leading authorities on this subject...
Cheers,
-- Scott
On Oct 19, 2006, at 1:32 PM, Yoshiki Ohshima wrote:
Anyway... it appears that disabling the #automaticKeyGeneration preference keeps the key-generation from happening at start-up, yet still allows publishing and loading projects, and still uses MySqueak as the default directory. Maybe that's all that's needed.
I would think so. Did you try to load a project published from an image in a directory into another image in another directory?
Or perhaps, for this build, would it make sense simply to include a pre-built squeak.keys file alongside the image, and not otherwise tamper with the security settings?
Yeah, I thought about this but I think it adds unnecessary complication.
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Hello,
Well, Michael is a bit unsure ;-)
Wow, hehe.
The key might still be in use for signing projects when publishing. If you download a project that was signed with your own key, the sandbox is not switched on. So having a single key for all users would be bad, because everyone would be trusted. Having no key means everyone would be distrusted, which is what we want I think.
We would have to test if projects are still interchangeable between machines with and without key (remember to remove the key from the secure directory). It might be that some file offset changes if the key is taken out.
By looking at the code that guesses the time to generate. It is really a guess. An aspect of it is that we can show for B-Test users that we honors security, and one time overhead of 90-120 seconds is not that bad for that.
I might vote for change the coefficient in the guess expression facter of 5 and limit the number display by 99%, and we keep the preference on.
-- Yoshiki
- Bert -
Am 20.10.2006 um 14:05 schrieb Scott Wallace:
I'll ask Andreas about this later today.
Meanwhile, perhaps Bert could speak with Michael about it as well.
Couldn't hurt to have the advice of the world's two leading authorities on this subject...
Cheers,
-- Scott
On Oct 19, 2006, at 1:32 PM, Yoshiki Ohshima wrote:
Anyway... it appears that disabling the #automaticKeyGeneration preference keeps the key-generation from happening at start-up, yet still allows publishing and loading projects, and still uses MySqueak as the default directory. Maybe that's all that's needed.
I would think so. Did you try to load a project published from an image in a directory into another image in another directory?
Or perhaps, for this build, would it make sense simply to include a pre-built squeak.keys file alongside the image, and not otherwise tamper with the security settings?
Yeah, I thought about this but I think it adds unnecessary complication.
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
How about just putting up an advisory message that says something like:
"This is a one-time pause to generate a special key to ensure security in Squeak Etoys"
I.e. just tell the end-user what you are doing. This will be sufficient for this build. (And the division by 5 sounds good.)
Cheers,
Alan
At 11:33 AM 10/20/2006, Yoshiki Ohshima wrote:
Hello,
Well, Michael is a bit unsure ;-)
Wow, hehe.
The key might still be in use for signing projects when publishing. If you download a project that was signed with your own key, the sandbox is not switched on. So having a single key for all users would be bad, because everyone would be trusted. Having no key means everyone would be distrusted, which is what we want I think.
We would have to test if projects are still interchangeable between machines with and without key (remember to remove the key from the secure directory). It might be that some file offset changes if the key is taken out.
By looking at the code that guesses the time to generate. It is really a guess. An aspect of it is that we can show for B-Test users that we honors security, and one time overhead of 90-120 seconds is not that bad for that.
I might vote for change the coefficient in the guess expression facter of 5 and limit the number display by 99%, and we keep the preference on.
-- Yoshiki
- Bert -
Am 20.10.2006 um 14:05 schrieb Scott Wallace:
I'll ask Andreas about this later today.
Meanwhile, perhaps Bert could speak with Michael about it as well.
Couldn't hurt to have the advice of the world's two leading authorities on this subject...
Cheers,
-- Scott
On Oct 19, 2006, at 1:32 PM, Yoshiki Ohshima wrote:
Anyway... it appears that disabling the #automaticKeyGeneration preference keeps the key-generation from happening at start-up, yet still allows publishing and loading projects, and still uses MySqueak as the default directory. Maybe that's all that's needed.
I would think so. Did you try to load a project published from an image in a directory into another image in another directory?
Or perhaps, for this build, would it make sense simply to include a pre-built squeak.keys file alongside the image, and not otherwise tamper with the security settings?
Yeah, I thought about this but I think it adds unnecessary complication.
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Etoys mailing list Etoys@laptop.org http://mailman.laptop.org/mailman/listinfo/etoys
Alan,
How about just putting up an advisory message that says something like:
"This is a one-time pause to generate a special key to ensure security in Squeak Etoys"
I.e. just tell the end-user what you are doing. This will be sufficient for this build. (And the division by 5 sounds good.)
Yeah, if #informDuring: would take multiple line string, it would be easy^^;
I'll probably put the message in a way that looks ok with the original progressing percent message. (I'd keep a way to inform something is really going on.)
-- Yoshiki
Hi Guys -
I just had a chat with Scott about the issues of key generation etc. It is important to understand what this mechanism is good for to understand what to do about it. So here is some history: In the early days of this mechanism at Disney we were concerned about someone slipping some code into a project file, get you to click on it and cause some harm. We decided to draw a line by using the sandbox model which disables access to files, disallows saving the image etc.
However, one of the issues that we (thought we) needed to deal with was how to determine whether to run in trusted or in sandboxed mode. We decided to do that by each machine generating its own private/public key pair and simply sign all projects. This allows us to determine when we load a project whether it was created on the machine and kick in the sand box if needed.
That was the theory. The praxis turned out differently. If there is a single thing that I feel we got really, really right for dealing with security was to enable the ability for users to drag and drop content from the OS onto Squeak and have it accept it even in sandboxed mode. Because of that mechanism, we really *never* had a need to run in trusted mode since anything an eToy user would ever do with files can be represented by drag and drop.
On OLPC we should draw the appropriate consequences from that experience. In short that means that the sandbox should simply always be on. And if we turn on the sandbox then we don't need any signing. However, since we're so close to the deadline I wouldn't recommend trying to get this done for this build. What I would recommend is the following:
* For this build only: Ship with a precomputed Squeak.keys file. The implication is that the machines in this build are indeed vulnerable to attacks if you load an eToy from an external source but since exposure of BTest-1 will be so limited I don't expect that to be a problem at all (basically all I expect people to do in reality is to show off the tutorial and examples).
* Right after the deadline: Turn on the sand box and turn off all the other security checks. There is really no reason for those if we're always running in the sandbox.
* Some time later: Figure out what the logical equivalent to the DnD interaction on OLPC would be. This depends largely on OLPC's view on how applications/activities exchange data; it could just be the clipboard.
Cheers, - Andreas
Andreas,
People will install the etoys package to their PC, so the keys will hang around there, and such PC may have valuable data in it. (In theory, we can have different packages for such...)
In the current image, securityChecksEnabled is on, and we put the one time notice upon the first start up, and there is no drag and drop yet.
For this build, I think the current status (in the repository) is ok.
-- Yoshiki
BTW, the Linux system and SSH on it seems to be generating secure key at the first start up. We would use that (or other content signing mechanism that OLPC would have.), instead of generating ourselves.
-- Yoshiki
Hi Yoshiki -
Yoshiki Ohshima wrote:
People will install the etoys package to their PC, so the keys will hang around there, and such PC may have valuable data in it. (In theory, we can have different packages for such...)
Uhm, I'm confused. I thought that the package we're making is for BTest-1 not for PCs and in particular not for *PC users* (contrary to developers)? What am I missing? Regardless...
For this build, I think the current status (in the repository) is ok.
... if you feel that the current status is fine, that's okay with me. From talking to Scott I had a different impression which is why I was trying to come up with options that would be acceptable for BTest-1. That's unrelated to the long-term plans btw, I think we'll want to have the sandbox on all the time and we should probably do that soon after the deadline.
Cheers, - Andreas
Andreas,
Yoshiki Ohshima wrote:
People will install the etoys package to their PC, so the keys will hang around there, and such PC may have valuable data in it. (In theory, we can have different packages for such...)
Uhm, I'm confused. I thought that the package we're making is for BTest-1 not for PCs and in particular not for *PC users* (contrary to developers)? What am I missing? Regardless...
There is a stuff called sugar-jhbuild for desktop Linux. It fetches all packages to recreate the necessary directory and file structure to "emulate" Sugar on it. Our packages are fetched in that way to the Linux desktops.
For this build, I think the current status (in the repository) is ok.
... if you feel that the current status is fine, that's okay with me. From talking to Scott I had a different impression which is why I was trying to come up with options that would be acceptable for BTest-1. That's unrelated to the long-term plans btw, I think we'll want to have the sandbox on all the time and we should probably do that soon after the deadline.
Yes, ok.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Bert Freudenberg -
Scott Wallace -
Scott Wallace -
Yoshiki Ohshima