[Building Sakai] Code Security (was Re: RSF Present and Future)

Steven Githens swgithen at mtu.edu
Sat Feb 6 07:42:46 PST 2010


Aaron Zeckoski wrote:
> For Matterhorn we mirror every java library that is used in it in our
> own maven repository and keep a copy of the compressed javascript
> libraries in our source code repository (basically we maintain a
> binary copy of all the things we depend on). We do not keep copies of
> the source code for these (which I think is what John is getting at).
> For Sakai, we basically do the same for the core of Sakai (not for
> contrib tools).
>
>   

That's awesome.  And I'm kind of hoping pretty soon that we'll have an 
ubuntu sakai-demo VM (with both current versions of s2 ands3) like 
matterhorn does where you can just throw it in VMWare Player.

And how awesome would it be to include include *all* the source for the 
entire stack of the VM, it's the ultimate XO-style OSS dream.  
Everything from the linux kernel, to the openjkd hotspot, to tomcat, to 
the Sakai stack.

I think a few parts of hotspot might still be proprietary, but I'm 
pretty sure the hotspot on apt-get is capable of running Sakai.

-s

> -AZ
>
>
> On Sat, Feb 6, 2010 at 10:41 AM, John Norman <john at caret.cam.ac.uk> wrote:
>   
>> Just on a trivial point
>>
>> On 6 Feb 2010, at 04:43, Steven Githens wrote:
>>
>> [...]
>>
>>     
>>> I'm pretty sure someone already did pull the plug and everything has
>>> been moved to fluid repositories.
>>>       
>> The project moved to Fluid first. If any plug has been pulled at Cambridge it was by the project owner. As a committed adopter of the Fluid project outputs, the Sakai 3 UX team see this as a natural development.
>>
>> This is just a detail, but I wanted to make clear that the project was not forced to move to Fluid, it was the preferred home of the project and Cambridge would have continued hosting indefinitely. Of course, indefinitely does not mean forever.
>>
>> I think there is a general principle here. For example, what should the Sakai UX folk do about JQuery? I imagine there are some libraries we assume will always be there and some that seem more vulnerable. Belt and braces thinking suggests we should seek to have a copy of any code used in a Sakai deployment under our own control, but I have not idea how big a storage burden that would create for us. It also suggests that we should have mirroring on our repositories for greater code security. Where should we draw the line?
>>
>> John
>>     
>
>
>   



More information about the sakai-dev mailing list