Re: [Sugar-devel] [FEATURE] Add can share/or not information to activities

[James Cameron]

I presume one reason for adding another thing is that max_participants
is not available to Sugar unless the activity is started.  The context
is to make decisions about showing activity icons on other computers,
not the computer running the activity?

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Add can share/or not information to activities

[Alan Jhonn Aguiar Schwyn]

Hi,
Why add another thing? ('can_share')
Make the things easy:
If self.max_participants = 1 thenthe activity can't be sharedelse   the 
activity can be shared
Regards
Alan
PS: this is not the current operation?
  ___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Visual Match-30

[Gary Martin]

Hi Walter,

When first launching Visual Match, the default computer mode behaviour that 
auto starts seems quite impossible for any human to compete with. I think it's 
just a *10 bug on the time-out, as the radio widget next to the robot head icon 
says 60 (I assume the unit is seconds), while the countdown before the computer 
move is triggered at 6 seconds.

I find it hard enough to play in single player mode, so a 6 second auto playing 
robot competitor gives me no chance what so ever ;)

--Gary

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Add can share/or not information to activities

[Gary Martin]

Hi Simon,

On 14 Nov 2011, at 18:38, Simon Schampijer wrote:

> Hi,
> 
> I would like to propose the following Feature for inclusion into Sugar: "Can 
> share" [1].
> 
> This feature will make it clearer if an activity can collaborate or not. So 
> far we know inside an Activity if it is able to be shared or not because the 
> share button is changing it's state accordingly (the button is made 
> insensitive if the activity does not support collaboration). But there are 
> other places that need to be aware if an activity supports collaboration or 
> not. For example the buddy palette in the neighborhood view where you can 
> invite a buddy to your activity. An invitation should only be possible if the 
> activity supports collaboration.
> 
> I propose to add a field to the activity.info file. This field should be 
> named 'can_share' ad takes the values 'yes' and 'no' (like the 
> 'show_launcher' field). The default value that is assumed if the field is not 
> set will be 'no'. The reason here is that the activity maintainer who cares 
> about collaboration sets the field and there are more activities that do NOT 
> support collaboration than there are who do.
> 
> The shell and the toolkit has to change, furthermore the activities that 
> support sharing have to change their activity.info file.

How does this relate to the self.max_participants = 1 value set inside current 
activities? Can it replace this previous api? If not, chances are will bump 
into bugs were the two values conflict and we end up with different parts of 
the UI showing different things. Is there any value in making 'can_share' an 
integer like 'self.max_participants' so the Sugar shell can know not to allow 
excess users into an activity that is already maxed out? Is anyone aware of any 
activities that actually use the self.max_participants for anything other than 
switching off collaboration UI?

--Gary

> 
> Regards,
>   Simon
> 
> [1] http://wiki.sugarlabs.org/go/Features/Can_share
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Fototoon icon redesign

[Gary Martin]

Hi Manuel,

On 11 Nov 2011, at 15:40, Manuel Quiñones wrote:

> Hi, did the change we discussed in the toolbar review talk for Fototoon icon:
> 
> http://dev.laptop.org/~manuq/fototoon_design/fototoon_icon.png

Thanks, looks much better.

--Gary

> Cheers,
> 
> -- 
> .. manuq ..
> 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar in Tuquito Distribution

[Thomas C Gilliard]

Alvar;

I just successfully downloaded the

tuquito-5-gnome-dvd-32bit.iso

from
http://tuquito.org.ar/descargar?f=tuquito41-main-32-mirror1

Listed on our the Community Distribution Page:
http://wiki.sugarlabs.org/go/Community/Distributions/tuquito (along with 
my notes)


And installed sugar 0.94.1 from Sweets-Distribution both as a gdm 
selection and in sugar-emulator.


I had previously used tuquito 4.1 this way

I have installed it in VirtualBox 4.1.6 for OSX and it works well.

Cordially

Tom Gilliard
satellit_

On 03/28/2011 08:14 AM, Alvar Maciel wrote:

On Mon, Mar 28, 2011 at 10:34 AM, Thomas C Gilliard<
satel...@bendbroadband.com>  wrote:


I have downloaded and tested tuquito in VirtualBox 4.0.4 OSX
I tried installing sweets-distribution on it and it works nicely.!

my notes and your note to us are here:
  http://wiki.sugarlabs.org/go/Community/Distributions/tuquito
I have also listed it here
  http://wiki.sugarlabs.org/go/Sugar_Creation_Kit#Community_Distributions
I need your permission to use the tuquito icon for this listing and for the
other page.

I plan to try other ways to install sugar (including directly from Ubuntu's
repo)

(SURF-115.xo needs to be finished and added to distributions repositories.)

  Cordially;

Tom Gilliard
satellit on IRC freenode #sugar

footnote: how is tuquito licensed?


Hey tom, thanks a lot for test tuquito and for add this one to sugar wiki

about tuquito logo feel free for use it please, you can get this one from
http://www.descargarlinux.com/wp-content/uploads/2011/01/tuquito.png


By the way we are packing sugar-jhbuild in deb format, so later you can
install latest sugar in tuquito (or other debian distributions) from
repositories directly. With this the browse problem is fixed because we are
going to put in our repositories the packahe xpcom
http://www.acercadelaeducacion.com.ar/scripts/python_xpcom.deb

another thing I have made a patch for add support to tuquito in sugar I sent
it to sugar labs but I dont know the exactly steps for add changes to
sugar-repo so I attached this patch in this email so you maybe can add this
or send to the rigth people


about tuquito license, it is licensed under GPL


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Global Text to Speech

[Samuel Klein]

+1  This would be amazing.  This would also encourage more people to
contribute to the speech engine for their language or dialect.

On Tue, Nov 15, 2011 at 9:15 AM, Gonzalo Odiard  wrote:

> I want propose the feature "Global Text to Speech" [1]
>
> In fact, the functionality was already designed, and part implemented, but
> is not working in Sugar.
>
> We have code in Speak, Read and Memorize activities implementing the call
> to the backend,
> the only missing part is a icon device to configure pitch and velocity.
>
> Gonzalo
>
> [1] http://wiki.sugarlabs.org/go/Features/GlobalTextToSpeech
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Samuel Klein  identi.ca:sj   w:user:sj  +1 617 529
4266
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Wrap icon for Log

[Rafael Ortiz]

On Tue, Nov 15, 2011 at 5:29 PM, James Cameron  wrote:

> On Tue, Nov 15, 2011 at 06:29:39PM -0300, Manuel Qui?ones wrote:
> > http://dev.laptop.org/~manuq/log_design/log_icon_wrap.png
>
> I like it.  Better than before.  Therefore I'd accept such a patch.
> Perhaps it could be better, but I'll wait until I see that, and won't
> delay accepting.
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

Also like it, it's better than the actual one.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Wrap icon for Log

[James Cameron]

On Tue, Nov 15, 2011 at 06:29:39PM -0300, Manuel Qui?ones wrote:
> http://dev.laptop.org/~manuq/log_design/log_icon_wrap.png

I like it.  Better than before.  Therefore I'd accept such a patch.
Perhaps it could be better, but I'll wait until I see that, and won't
delay accepting.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Wrap icon for Log

[Frederick Grose]

2011/11/15 Manuel Quiñones 

> Hi,
>
> Agustín Zubiaga is working with my help in toolbars.  He is a very
> promissing volunteer, a boy from Uruguay.  We want to know what do you
> think about changing the wrap icon in Log for this one:
>
> http://dev.laptop.org/~manuq/log_design/log_icon_wrap.png
>
> Currently, the button reuses the text align left icon.
>
> Cheers,
>
> --
> .. manuq ..


That looks promising.  Placing a long line before the arrow may be more
telling.
(Then, alternate the long and short lines to keep the balance.)

 --Fred
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] Wrap icon for Log

[Manuel Quiñones]

Hi,

Agustín Zubiaga is working with my help in toolbars.  He is a very
promissing volunteer, a boy from Uruguay.  We want to know what do you
think about changing the wrap icon in Log for this one:

http://dev.laptop.org/~manuq/log_design/log_icon_wrap.png

Currently, the button reuses the text align left icon.

Cheers,

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Create new owner keys as RSA keys instead of DSA

[James Cameron]

Reviewed-by: James Cameron 

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Portfolio-17

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4437

Sugar Platform:
0.82 - 0.96

Download Now:
http://activities.sugarlabs.org/downloads/file/27732/portfolio-17.xo

Release notes:
17

ENHANCEMENTS:
* Spanish translation of new audio note recording strings
* Audio playback button enabled whenever an audio note is available


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Portfolio-16

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4437

Sugar Platform:
0.82 - 0.96

Download Now:
http://activities.sugarlabs.org/downloads/file/27731/portfolio-16.xo

Release notes:
16

ENHANCEMENTS:
* Audio tags (the student can record audio notes to be played back with each 
portfolio entry)
* New translations
* Cairo graphics


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Walter Bender]

On Tue, Nov 15, 2011 at 12:51 PM, Kevin Gordon  wrote:
>
>
> On Tue, Nov 15, 2011 at 9:07 AM, Christoph Derndorfer
>  wrote:
>>
>> On Tue, Nov 15, 2011 at 2:50 PM, Gonzalo Odiard 
>> wrote:
>>>
>>>
>>> On Tue, Nov 15, 2011 at 10:23 AM, Simon Schampijer 
>>> wrote:

 El 15/11/11 14:06, Gonzalo Odiard escribió:
>
> One problem with transfer to many, is, when the users do not have a
> school
> server, and use the ad-hoc networks,
> usually they group the kids in 3 groups and the teacher will need send
> to
> all in one group, check all have received,
> go to the next group send to all, etc.

 Hmm, what is the issue they are facing. Do you mean the Ad-hoc network
 is not capable of sending that many files at once?
>>>
>>> Yes, and then the use will be more difficult to the teacher, than sharing
>>> a file and enable the kids to download it.
>>
>> Just out of curiosity: Do we have any data or half-decent estimates on
>> what rough percentage of current Sugar users are working in ad-hoc mode vs.
>> infrastructure mode?
>> That could help inform this decision, especially in terms of whether we
>> might need one or two different ways to do this (e.g. trying to send the
>> files sequentially vs. in parallel while in ad-hoc mode might be an option).
>> Cheers,
>> Christoph
>>
>>
>
>
>
> If anyone is interested, and I wont clutter the post by diverting too much
> here from what looks to be an elegant solution in the making,  Please just
> ping me off-list if you want to see the specifics; but briefly here's our
> q&d solution where the only technology oniste is:  XO 1.0's, hardly
> any power, and a DHCP enabled wireless access point, and some pre-populated
> SD cards with bunches of books.
>  :
> Especially now with the new sugar ability to see items in the documents
> folder, this is a pretty simple setup where the teacher is running pure-ftpd
> (scripted install),  and serves up his/her SD card.   The student users just
> ftp client in to get the docs they want and the download process stores them
> in their documents folder.  We use this to refresh the ebooks on the student
> XO's so that they can read in a disconnected environment via sugar READ. We
> do this because sometimes they get deleted, sometimes they get corrupted,
> and this lets them get what they need and not have to fill up all of their
> available space with all the books, just the ones they need at the
> moment. Once on the desired XO's, all of the other collabortive
> functionality is there, of course.  It's no XS server, and it isnt an
> elegant collabortive or multi-cast distribution network, but ...
>

+1 to keeping it simple!!

-walter

> Cheers
>
> KG
>>
>>
>>
>>>
>>> Gonzalo
>>>
>>>

 Or is it the representation of the file transfers in the sugar UI? For
 the latter the idea is to adjust the file transfer notification being only
 one item in the activity tray containing all the notifications.

>>>
>>>
>>>
>>>

 Regards,
   Simon
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>>
>>
>> --
>> Christoph Derndorfer
>> editor, OLPC News [www.olpcnews.com]
>> volunteer, OLPC (Austria) [www.olpc.at]
>> e-mail: christ...@derndorfer.eu
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Kevin Gordon]

On Tue, Nov 15, 2011 at 9:07 AM, Christoph Derndorfer <
christoph.derndor...@gmail.com> wrote:

> On Tue, Nov 15, 2011 at 2:50 PM, Gonzalo Odiard wrote:
>
>>
>>
>> On Tue, Nov 15, 2011 at 10:23 AM, Simon Schampijer 
>> wrote:
>>
>>> El 15/11/11 14:06, Gonzalo Odiard escribió:
>>>
>>>  One problem with transfer to many, is, when the users do not have a
 school
 server, and use the ad-hoc networks,
 usually they group the kids in 3 groups and the teacher will need send
 to
 all in one group, check all have received,
 go to the next group send to all, etc.

>>>
>>> Hmm, what is the issue they are facing. Do you mean the Ad-hoc network
>>> is not capable of sending that many files at once?
>>
>>
>> Yes, and then the use will be more difficult to the teacher, than sharing
>> a file and enable the kids to download it.
>>
>
> Just out of curiosity: Do we have any data or half-decent estimates on
> what rough percentage of current Sugar users are working in ad-hoc mode vs.
> infrastructure mode?
>
> That could help inform this decision, especially in terms of whether we
> might need one or two different ways to do this (e.g. trying to send the
> files sequentially vs. in parallel while in ad-hoc mode might be an option).
>
> Cheers,
> Christoph
>
>
>


If anyone is interested, and I wont clutter the post by diverting too much
here from what looks to be an elegant solution in the making,  Please just
ping me off-list if you want to see the specifics; but briefly here's our
q&d solution where the only technology oniste is:  XO 1.0's, hardly
any power, and a DHCP enabled wireless access point, and some pre-populated
SD cards with bunches of books.
 :
Especially now with the new sugar ability to see items in the documents
folder, this is a pretty simple setup where the teacher is running
pure-ftpd (scripted install),  and serves up his/her SD card.   The student
users just ftp client in to get the docs they want and the download process
stores them in their documents folder.  We use this to refresh
the ebooks on the student XO's so that they can read in a disconnected
environment via sugar READ. We do this because sometimes they get deleted,
sometimes they get corrupted, and this lets them get what they need and not
have to fill up all of their available space with all the books, just the
ones they need at the moment. Once on the desired XO's, all of the other
collabortive functionality is there, of course.  It's no XS server, and it
isnt an elegant collabortive or multi-cast distribution network, but ...

Cheers

KG

>
>
>
>
>> Gonzalo
>>
>>
>>
>>> Or is it the representation of the file transfers in the sugar UI? For
>>> the latter the idea is to adjust the file transfer notification being only
>>> one item in the activity tray containing all the notifications.
>>>
>>>
>>
>>
>>
>>
>>> Regards,
>>>   Simon
>>>
>>> __**_
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.**org 
>>> http://lists.sugarlabs.org/**listinfo/sugar-devel
>>>
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
>
> --
> Christoph Derndorfer
>
> editor, OLPC News [www.olpcnews.com]
> volunteer, OLPC (Austria) [www.olpc.at]
>
> e-mail: christ...@derndorfer.eu
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] error building etoys in a debian distro

[Jonas Smedegaard]

Hi Alvar,

On 11-11-14 at 03:28pm, Alvar Maciel wrote:
> I'm trying to compile debian from source ina Debian 6.0 Distribution.
> The goal is build the .deb packages of sugar 0.94.1 because in my
> country (Argentina) there is a deployment of classmate with tjis
> distribution and are almost 400,000 machines to students of primary
> school. I think that this is an opportunity to  use sugar, so my
> summer project it's build this package.

I cannot help you with your concrete issue, as that is tied to jh-build 
which I don't use.

Are you aware that Debian has official Debian packages for Sugar 0.84?

Would be awesome if you could see the benefit of joining us in improving 
those packages distributed globally instead of locally struggling with 
jh-build.


Kind regards,

 - Jonas

Debian package maintainer for Sugar packages

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [MINUTES] Development team meeting --- 15. Nov 2011 (15:00 UTC)

[Simon Schampijer]

Hi,

for those that could not attend, here the logs:

Minutes: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-11-15T15:02:54.html
meeting: Log: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-11-15T15:02:54


Regards,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH 2/2 sugar] Create new owner keys as RSA keys instead of DSA

[Sascha Silbe]

Excerpts from Samuel Greenfeld's message of 2011-11-15 15:23:58 +0100:

> Has anyone in the security field (such as Ivan Krstić) reviewed this
> proposal?  Are there any potential performance impacts by switching key
> types for slower systems such as the XO-1?

A few quick tests have shown no significant differences in ssh-keygen
runtime (if anything RSA key generation is faster). As stated before, no
other piece of code does cryptographic operations with the key, so
there's neither a performance impact nor a need for an independent
security review for the two patches. The most important cryptographic
open source tools (GnuPG, SSH, Mozilla NSS) default to using RSA keys,
so using RSA keys for future cryptographic operations in Sugar is a
reasonable choice.

I wouldn't mind if anyone asked Ivan Krstić, Bruce Perens or any other
reputable computer security expert for their opinion, of course.


> We may also want to support handling an ECDSA SSH key if we see one,
> although generating one may not always be possible (some distributions
> remove this algorithm due to patent concerns).

ECC is out of scope for this patch. The purpose is to make the key
compatible with more software, not less. ECC support in most
cryptographic toolkits ranges from experimental to non-existent.
 
Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Global Text to Speech

[Chris Leonard]

On Tue, Nov 15, 2011 at 9:15 AM, Gonzalo Odiard  wrote:
> I want propose the feature "Global Text to Speech" [1]
>
> In fact, the functionality was already designed, and part implemented, but
> is not working in Sugar.
>
> We have code in Speak, Read and Memorize activities implementing the call to
> the backend,
> the only missing part is a icon device to configure pitch and velocity.
>
> Gonzalo
>
> [1] http://wiki.sugarlabs.org/go/Features/GlobalTextToSpeech
>


I believe the list of "speaking" activities is greater than that
(based on the PO files containing the languages from e-speak and other
hints).

See also:
jigsaw-puzzle
slider-puzzle
clock

The e-speak code contains it's own set of language names, limited to
those present in the upstream e-speak collection A(fairly limited).
It might be nice if the activities chose a sensible default based on
locale, but still offered the speak control options.

Harmonizing the language and parameter selection stuff across speaking
activities would be a L10n win if it eliminated some strings across
activities by centralizing them elsewhere..  These translator comments
from the last few strings of Clock might be helpful on the e-speak
parameter stuff.

TRANS: The language pitch (range [0 - 99], default 50 for English)
Look at http://espeak.sourceforge.net/commands.html for details

TRANS: The diction speed, in average words per minute (range [80 -
390], default 170 for English).
Look at http://espeak.sourceforge.net/commands.html for details

TRANS: The pause duration between words, in units of 10 ms.
Look at http://espeak.sourceforge.net/commands.html for details

TRANS: The language and voice variant
Look at http://espeak.sourceforge.net/commands.html for details, and
http://espeak.sourceforge.net/languages.html to see if your language
is supported.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH 2/2 sugar] Create new owner keys as RSA keys instead of DSA

[Walter Bender]

On Tue, Nov 15, 2011 at 9:23 AM, Samuel Greenfeld  wrote:
> My last two jobs significantly involved encryption, but I am not that good
> of an amateur cryptographer.
>
> Has anyone in the security field (such as Ivan Krstić) reviewed this
> proposal?  Are there any potential performance impacts by switching key
> types for slower systems such as the XO-1?
>
> We may also want to support handling an ECDSA SSH key if we see one,
> although generating one may not always be possible (some distributions
> remove this algorithm due to patent concerns).

As I recall, Fedora pulled support for ECDSA due to patent concerns,
hence we abandoned that route relatively early-on in the Sugar
development process.

-walter
>
> ---
> SJG
>
>
> On Tue, Nov 15, 2011 at 7:35 AM, Sascha Silbe 
> wrote:
>>
>> Sugar currently uses the owner key as an opaque string, not as an actual
>> key.
>> This means the key type does not yet matter, we can just as easily use an
>> RSA
>> key. The most important reason to prefer DSA over RSA, the RSA patent, has
>> expired in 2000 [1]. While DSA is considered secure when used correctly,
>> it
>> relies on certain properties (e.g. a cryptographically secure PRNG [1])
>> that
>> have not always been met in practice [3], with secret key exposure as a
>> result [4]. RSA is less problematic in this regard.
>>
>> RSA keys are also more readily usable with other tools (e.g. monkeysphere
>> only
>> supports RSA keys [5]), enabling Sugar to use a single key to identify the
>> user for other protocols and purposes than just Collaboration. Examples
>> that
>> come to mind instantly are web browsing (think a.sl.o) and email
>> (OpenPGP).
>>
>> [1] http://en.wikipedia.org/wiki/RSA
>> [2] http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/
>> [3] http://www.debian.org/security/2008/dsa-1571
>> [4]
>> http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/
>> [5] http://web.monkeysphere.info/news/release-0.24-1/
>>
>> Signed-off-by: Sascha Silbe 
>> ---
>>  src/jarabe/intro/window.py |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/jarabe/intro/window.py b/src/jarabe/intro/window.py
>> index f7937b1..6cf1481 100644
>> --- a/src/jarabe/intro/window.py
>> +++ b/src/jarabe/intro/window.py
>> @@ -47,7 +47,7 @@ def create_profile(name, color=None):
>>     import commands
>>     keypath = os.path.join(env.get_profile_path(), 'owner.key')
>>     if not os.path.isfile(keypath):
>> -        cmd = "ssh-keygen -q -t dsa -f %s -C '' -N ''" % keypath
>> +        cmd = "ssh-keygen -q -t rsa -f %s -C '' -N ''" % keypath
>>         (s, o) = commands.getstatusoutput(cmd)
>>         if s != 0:
>>             logging.error('Could not generate key pair: %d %s', s, o)
>> --
>> 1.7.7.1
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Global Text to Speech

[Gonzalo Odiard]

I am already working on that ;)


> Also, we need to deHippo the speak code :P
>
> -walter
>
> >
> > Gonzalo
> >
> > [1] http://wiki.sugarlabs.org/go/Features/GlobalTextToSpeech
> >
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Hello World-4

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4418

Sugar Platform:
0.96 - 0.96

Download Now:
http://activities.sugarlabs.org/downloads/file/27730/helloworld-4.xo

Release notes:
Port hello-world to gtk3 and the new sugar toolkit (Simon Schampijer)


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GTK2 and GTK3 versions in ASLO

[Manuel Quiñones]

You can dismiss the previous email.

After talking with Gonzalo, he reminded me that what we need is minor
versions for gtk2 releases, like 42.1, 42.2, etc, and major versions
for gtk3, 43, 44, etc.

It seems possible with ASLO, selecting the proper Sugar Platform in
Compatible Aplications.

El día 15 de noviembre de 2011 10:54, Manuel Quiñones
 escribió:
> OK so it seems that ASLO can handle two versions of an activity, one
> for GTK2 and one for GTK3.
>
> I did a mock activity "MelloWorld" in two versions, GTK2 and GTK3,
> appended that information to the activity_version in activity.info,
> like:
>
> activity_version = 3.GTK3
>
> Then did python ./setup.py dist_xo and uploaded the two files.  Result:
>
> http://wiki.sugarlabs.org/images/4/44/Aslo-test-versions.png
>
> Maybe add GTK2/GTK3 in the Compatible Aplications, like Sugar Platform?
>
> http://wiki.sugarlabs.org/images/b/bc/Aslo-test-versions-2.png
>
> Cheers,
>
> --
> .. manuq ..
>



-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH 2/2 sugar] Create new owner keys as RSA keys instead of DSA

[Samuel Greenfeld]

My last two jobs significantly involved encryption, but I am not that good
of an amateur cryptographer.

Has anyone in the security field (such as Ivan Krstić) reviewed this
proposal?  Are there any potential performance impacts by switching key
types for slower systems such as the XO-1?

We may also want to support handling an ECDSA SSH key if we see one,
although generating one may not always be possible (some distributions
remove this algorithm due to patent concerns).

---
SJG


On Tue, Nov 15, 2011 at 7:35 AM, Sascha Silbe wrote:

> Sugar currently uses the owner key as an opaque string, not as an actual
> key.
> This means the key type does not yet matter, we can just as easily use an
> RSA
> key. The most important reason to prefer DSA over RSA, the RSA patent, has
> expired in 2000 [1]. While DSA is considered secure when used correctly, it
> relies on certain properties (e.g. a cryptographically secure PRNG [1])
> that
> have not always been met in practice [3], with secret key exposure as a
> result [4]. RSA is less problematic in this regard.
>
> RSA keys are also more readily usable with other tools (e.g. monkeysphere
> only
> supports RSA keys [5]), enabling Sugar to use a single key to identify the
> user for other protocols and purposes than just Collaboration. Examples
> that
> come to mind instantly are web browsing (think a.sl.o) and email (OpenPGP).
>
> [1] http://en.wikipedia.org/wiki/RSA
> [2] http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/
> [3] http://www.debian.org/security/2008/dsa-1571
> [4]
> http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/
> [5] http://web.monkeysphere.info/news/release-0.24-1/
>
> Signed-off-by: Sascha Silbe 
> ---
>  src/jarabe/intro/window.py |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/jarabe/intro/window.py b/src/jarabe/intro/window.py
> index f7937b1..6cf1481 100644
> --- a/src/jarabe/intro/window.py
> +++ b/src/jarabe/intro/window.py
> @@ -47,7 +47,7 @@ def create_profile(name, color=None):
> import commands
> keypath = os.path.join(env.get_profile_path(), 'owner.key')
> if not os.path.isfile(keypath):
> -cmd = "ssh-keygen -q -t dsa -f %s -C '' -N ''" % keypath
> +cmd = "ssh-keygen -q -t rsa -f %s -C '' -N ''" % keypath
> (s, o) = commands.getstatusoutput(cmd)
> if s != 0:
> logging.error('Could not generate key pair: %d %s', s, o)
> --
> 1.7.7.1
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Global Text to Speech

[Walter Bender]

On Tue, Nov 15, 2011 at 9:15 AM, Gonzalo Odiard  wrote:
> I want propose the feature "Global Text to Speech" [1]
>
> In fact, the functionality was already designed, and part implemented, but
> is not working in Sugar.
>
> We have code in Speak, Read and Memorize activities implementing the call to
> the backend,
> the only missing part is a icon device to configure pitch and velocity.

Also, we need to deHippo the speak code :P

-walter

>
> Gonzalo
>
> [1] http://wiki.sugarlabs.org/go/Features/GlobalTextToSpeech
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] HelloWorld-4

[Simon Schampijer]

== Source ==

http://download.sugarlabs.org/sources/sucrose/fructose/HelloWorld/HelloWorld-4.tar.bz2

== News ==

* Release 4 (Simon Schampijer)
* Port hello-world to gtk3 and the new sugar toolkit (Simon Schampijer)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [FEATURE] Global Text to Speech

[Gonzalo Odiard]

I want propose the feature "Global Text to Speech" [1]

In fact, the functionality was already designed, and part implemented, but
is not working in Sugar.

We have code in Speak, Read and Memorize activities implementing the call
to the backend,
the only missing part is a icon device to configure pitch and velocity.

Gonzalo

[1] http://wiki.sugarlabs.org/go/Features/GlobalTextToSpeech
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Christoph Derndorfer]

On Tue, Nov 15, 2011 at 2:50 PM, Gonzalo Odiard  wrote:

>
>
> On Tue, Nov 15, 2011 at 10:23 AM, Simon Schampijer wrote:
>
>> El 15/11/11 14:06, Gonzalo Odiard escribió:
>>
>>  One problem with transfer to many, is, when the users do not have a
>>> school
>>> server, and use the ad-hoc networks,
>>> usually they group the kids in 3 groups and the teacher will need send to
>>> all in one group, check all have received,
>>> go to the next group send to all, etc.
>>>
>>
>> Hmm, what is the issue they are facing. Do you mean the Ad-hoc network is
>> not capable of sending that many files at once?
>
>
> Yes, and then the use will be more difficult to the teacher, than sharing
> a file and enable the kids to download it.
>

Just out of curiosity: Do we have any data or half-decent estimates on what
rough percentage of current Sugar users are working in ad-hoc mode vs.
infrastructure mode?

That could help inform this decision, especially in terms of whether we
might need one or two different ways to do this (e.g. trying to send the
files sequentially vs. in parallel while in ad-hoc mode might be an option).

Cheers,
Christoph



> Gonzalo
>
>
>
>> Or is it the representation of the file transfers in the sugar UI? For
>> the latter the idea is to adjust the file transfer notification being only
>> one item in the activity tray containing all the notifications.
>>
>>
>
>
>
>
>> Regards,
>>   Simon
>>
>> __**_
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.**org 
>> http://lists.sugarlabs.org/**listinfo/sugar-devel
>>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Christoph Derndorfer

editor, OLPC News [www.olpcnews.com]
volunteer, OLPC (Austria) [www.olpc.at]

e-mail: christ...@derndorfer.eu
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] GTK2 and GTK3 versions in ASLO

[Manuel Quiñones]

OK so it seems that ASLO can handle two versions of an activity, one
for GTK2 and one for GTK3.

I did a mock activity "MelloWorld" in two versions, GTK2 and GTK3,
appended that information to the activity_version in activity.info,
like:

activity_version = 3.GTK3

Then did python ./setup.py dist_xo and uploaded the two files.  Result:

http://wiki.sugarlabs.org/images/4/44/Aslo-test-versions.png

Maybe add GTK2/GTK3 in the Compatible Aplications, like Sugar Platform?

http://wiki.sugarlabs.org/images/b/bc/Aslo-test-versions-2.png

Cheers,

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Gonzalo Odiard]

On Tue, Nov 15, 2011 at 10:23 AM, Simon Schampijer wrote:

> El 15/11/11 14:06, Gonzalo Odiard escribió:
>
>  One problem with transfer to many, is, when the users do not have a school
>> server, and use the ad-hoc networks,
>> usually they group the kids in 3 groups and the teacher will need send to
>> all in one group, check all have received,
>> go to the next group send to all, etc.
>>
>
> Hmm, what is the issue they are facing. Do you mean the Ad-hoc network is
> not capable of sending that many files at once?


Yes, and then the use will be more difficult to the teacher, than sharing a
file and enable the kids to download it.

Gonzalo



> Or is it the representation of the file transfers in the sugar UI? For the
> latter the idea is to adjust the file transfer notification being only one
> item in the activity tray containing all the notifications.
>
>




> Regards,
>   Simon
>
> __**_
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.**org 
> http://lists.sugarlabs.org/**listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Simon Schampijer]

El 15/11/11 14:06, Gonzalo Odiard escribió:

One problem with transfer to many, is, when the users do not have a school
server, and use the ad-hoc networks,
usually they group the kids in 3 groups and the teacher will need send to
all in one group, check all have received,
go to the next group send to all, etc.


Hmm, what is the issue they are facing. Do you mean the Ad-hoc network 
is not capable of sending that many files at once? Or is it the 
representation of the file transfers in the sugar UI? For the latter the 
idea is to adjust the file transfer notification being only one item in 
the activity tray containing all the notifications.


Regards,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] error building etoys in a debian distro

[Bert Freudenberg]

On 14.11.2011, at 19:28, Alvar Maciel wrote:

> Subject: error building etoys in a debian distro
> Hi to all,
> I'm trying to compile debian from source ina Debian 6.0 Distribution.
> The goal is build the .deb packages of sugar 0.94.1 because in my
> country (Argentina) there is a deployment of classmate with tjis
> distribution and are almost 400,000 machines to students of primary
> school. I think that this is an opportunity to  use sugar, so my
> summer project it's build this package.
> The only problem that I have (for now) it's in the building of etoys.
> this is the message:
> ln -sf activity-etoys.svg
> /opt/sugar-jhbuild/install/share/sugar/activities/Etoys.activity/activity/$f.svg
> ; \
>   done
> update-mime-database /opt/sugar-jhbuild/install/share/mime
> *** Error durante la fase install de etoys: Module failed to install
> into DESTDIR u'/opt/sugar-jhbuild/install/_jhbuild/root-etoys-broken'
> *** [1/1]
> 
> any help?

Hi Alvar,

I'm not really familiar with the Debian packages, but perhaps the 
shared-mime-info package is not installed? Assuming it's the 
update-mime-database command that failed.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Gonzalo Odiard]

One problem with transfer to many, is, when the users do not have a school
server, and use the ad-hoc networks,
usually they group the kids in 3 groups and the teacher will need send to
all in one group, check all have received,
go to the next group send to all, etc.

Read activity implement a web server to share the book file, and a message
to say to the client what download.
May be we can create a simple "Share File" activity, and when the user
select Share in the Journal, start this activity
sharing the file.

Gonzalo

On Tue, Nov 15, 2011 at 9:39 AM, Walter Bender wrote:

> On Tue, Nov 15, 2011 at 6:40 AM, Simon Schampijer 
> wrote:
> > Hi,
> >
> > I would like to propose the following Feature for inclusion into Sugar:
> > "Transfer to many" [1].
> >
> > At the moment it is only possible to transfer a Journal entry to another
> > learner one by one. Teachers have asked that they would like to transfer
> a
> > file to all the class for example easily (hand out a book, assignment
> etc).
>
> Not the only possible way: if a book is shared in the neighborhood
> view, each child can download it by joining the Read activity. In your
> proposal, I presume each child needs to accept the transfer
> notification, so there has to be an action taken by each intended
> recipient in any case. The difference being that book won't be opened
> at the time of transfer in your scenario (not sure that is a feature).
> But presumably teachers don't like this method?
>
> >
> > One simple idea is to add an entry to the Journal item palette that does
> a
> > 'send-to-all friends'. The question is where to place the option in the
> > palette. As the first option which might cause accidental triggering.
> > Furthermore the way we handle the transfer related notifications in the
> > frame should change (as described at [2]).
> >
> > A long standing issue that does play into that discussion is grouping of
> > learners. Currently the only option to group a number of people is to
> friend
> > them.
>
> Is that so unreasonable? Adding all of the children in a class -- once
> -- at the beginning of the term?
>
> >
> > Regards,
> >   Simon
> >
> > [1] http://wiki.sugarlabs.org/go/Features/Transfer_to_many#UI_Design
> > [2]
> http://lists.sugarlabs.org/archive/sugar-devel/2011-November/034198.html
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
>
> regards.
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Simon Schampijer]

El 15/11/11 13:39, Walter Bender escribió:

On Tue, Nov 15, 2011 at 6:40 AM, Simon Schampijer  wrote:

Hi,

I would like to propose the following Feature for inclusion into Sugar:
"Transfer to many" [1].

At the moment it is only possible to transfer a Journal entry to another
learner one by one. Teachers have asked that they would like to transfer a
file to all the class for example easily (hand out a book, assignment etc).


Not the only possible way: if a book is shared in the neighborhood
view, each child can download it by joining the Read activity. In your
proposal, I presume each child needs to accept the transfer
notification, so there has to be an action taken by each intended
recipient in any case. The difference being that book won't be opened
at the time of transfer in your scenario (not sure that is a feature).
But presumably teachers don't like this method?


I think transferring with a group of learners any Journal entry is the 
goal. Read (transfer a book) is only one case, it will break for others.



One simple idea is to add an entry to the Journal item palette that does a
'send-to-all friends'. The question is where to place the option in the
palette. As the first option which might cause accidental triggering.
Furthermore the way we handle the transfer related notifications in the
frame should change (as described at [2]).

A long standing issue that does play into that discussion is grouping of
learners. Currently the only option to group a number of people is to friend
them.


Is that so unreasonable? Adding all of the children in a class -- once
-- at the beginning of the term?


It brakes if you consider several classes? Groups come into play here as 
well, which have been discussed before already [1].


Regards,
   Simon

[1] http://wiki.sugarlabs.org/go/Features/Transfer_to_many#Documentation
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Transfer to many

[Walter Bender]

On Tue, Nov 15, 2011 at 6:40 AM, Simon Schampijer  wrote:
> Hi,
>
> I would like to propose the following Feature for inclusion into Sugar:
> "Transfer to many" [1].
>
> At the moment it is only possible to transfer a Journal entry to another
> learner one by one. Teachers have asked that they would like to transfer a
> file to all the class for example easily (hand out a book, assignment etc).

Not the only possible way: if a book is shared in the neighborhood
view, each child can download it by joining the Read activity. In your
proposal, I presume each child needs to accept the transfer
notification, so there has to be an action taken by each intended
recipient in any case. The difference being that book won't be opened
at the time of transfer in your scenario (not sure that is a feature).
But presumably teachers don't like this method?

>
> One simple idea is to add an entry to the Journal item palette that does a
> 'send-to-all friends'. The question is where to place the option in the
> palette. As the first option which might cause accidental triggering.
> Furthermore the way we handle the transfer related notifications in the
> frame should change (as described at [2]).
>
> A long standing issue that does play into that discussion is grouping of
> learners. Currently the only option to group a number of people is to friend
> them.

Is that so unreasonable? Adding all of the children in a class -- once
-- at the beginning of the term?

>
> Regards,
>   Simon
>
> [1] http://wiki.sugarlabs.org/go/Features/Transfer_to_many#UI_Design
> [2] http://lists.sugarlabs.org/archive/sugar-devel/2011-November/034198.html
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

regards.

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH 2/2 sugar] Create new owner keys as RSA keys instead of DSA

[Sascha Silbe]

Sugar currently uses the owner key as an opaque string, not as an actual key.
This means the key type does not yet matter, we can just as easily use an RSA
key. The most important reason to prefer DSA over RSA, the RSA patent, has
expired in 2000 [1]. While DSA is considered secure when used correctly, it
relies on certain properties (e.g. a cryptographically secure PRNG [1]) that
have not always been met in practice [3], with secret key exposure as a
result [4]. RSA is less problematic in this regard.

RSA keys are also more readily usable with other tools (e.g. monkeysphere only
supports RSA keys [5]), enabling Sugar to use a single key to identify the
user for other protocols and purposes than just Collaboration. Examples that
come to mind instantly are web browsing (think a.sl.o) and email (OpenPGP).

[1] http://en.wikipedia.org/wiki/RSA
[2] http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/
[3] http://www.debian.org/security/2008/dsa-1571
[4] http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/
[5] http://web.monkeysphere.info/news/release-0.24-1/

Signed-off-by: Sascha Silbe 
---
 src/jarabe/intro/window.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/jarabe/intro/window.py b/src/jarabe/intro/window.py
index f7937b1..6cf1481 100644
--- a/src/jarabe/intro/window.py
+++ b/src/jarabe/intro/window.py
@@ -47,7 +47,7 @@ def create_profile(name, color=None):
 import commands
 keypath = os.path.join(env.get_profile_path(), 'owner.key')
 if not os.path.isfile(keypath):
-cmd = "ssh-keygen -q -t dsa -f %s -C '' -N ''" % keypath
+cmd = "ssh-keygen -q -t rsa -f %s -C '' -N ''" % keypath
 (s, o) = commands.getstatusoutput(cmd)
 if s != 0:
 logging.error('Could not generate key pair: %d %s', s, o)
--
1.7.7.1

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH 1/2 sugar-toolkit] Accept RSA key as owner key

[Sascha Silbe]

Sugar currently uses the owner key as an opaque string, not as an actual key.
This means the key type doesn't matter, we can just as easily use an RSA key.

Signed-off-by: Sascha Silbe 
---
 src/sugar/profile.py |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/sugar/profile.py b/src/sugar/profile.py
index c1dffd7..a38b908 100644
--- a/src/sugar/profile.py
+++ b/src/sugar/profile.py
@@ -91,12 +91,12 @@ class Profile(object):
 logging.exception('Error reading public key')
 return None
 
-magic = 'ssh-dss '
+magic = ('ssh-dss ', 'ssh-rsa ')
 for l in lines:
 l = l.strip()
 if not l.startswith(magic):
 continue
-return l[len(magic):]
+return l[len(magic[0]):]
 else:
 logging.error('Error parsing public key.')
 return None
@@ -120,10 +120,12 @@ class Profile(object):
 end_found = False
 for l in lines:
 l = l.strip()
-if l.startswith('-BEGIN DSA PRIVATE KEY-'):
+if l.startswith(('-BEGIN DSA PRIVATE KEY-',
+ '-BEGIN RSA PRIVATE KEY-')):
 begin_found = True
 continue
-if l.startswith('-END DSA PRIVATE KEY-'):
+if l.startswith(('-END DSA PRIVATE KEY-',
+ '-END RSA PRIVATE KEY-')):
 end_found = True
 continue
 key += l
-- 
1.7.7.1

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Create new owner keys as RSA keys instead of DSA

[Sascha Silbe]

The following patch set changes the type of keys created by the intro
screen from DSA to RSA. As no part of the Sugar platform actually uses
them as keys yet (only hash sums are used), now is a good time to do
this change.

There are a couple of reasons to prefer RSA over DSA, one of which is
better compatibility with other parts of the software stack, making it
easier to implement the Bitfrost identity service (P_IDENT [1]).

By changing the default key type now, we reduce the number of systems
that would need to recreate keys (and thus changing their identity) once
P_IDENT (or anything else that needs RSA keys) gets implemented. So even
(or rather: especially) if nobody works on the identity service in the
near future, we should merge this patch to make future upgrades as
seamless as possible.

I've checked the key related code in sugar, sugar-presence-service and
sugar-toolkit. Besides one unimportant occurence in
sugar-presence-service (see below), only the functions for reading the
key from disk (in sugar-toolkit) don't treat the key as just an opaque
string. The first patch fixes these to accept RSA keys in addition to
DSA keys.

In addition to the code audit and checking the protocol specs (that
don't say anything useful about the key), I've tested Collaboration
between two systems running latest sugar-jhbuild on Debian Squeeze
resp. Wheezy, with the Squeeze one having a DSA key (and no patches)
and the Wheezy one sporting the two patches and an RSA key. As expected,
no regression occured.

src/pstest.py in sugar-presence-service also contains code to create and
parse DSA keys. Since sugar-presence-service is deprecated and pstest.py
isn't used during normal operation, I've not bothered to make it use RSA
keys instead.

Sascha Silbe (2):
  [sugar-toolkit] Accept RSA key as owner key
  [sugar] Create new owner keys as RSA keys instead of DSA

 src/sugar/profile.py |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

 src/jarabe/intro/window.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


[1] http://wiki.laptop.org/go/OLPC_Bitfrost#P_IDENT:_identity_service
--
1.7.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [FEATURE] Transfer to many

[Simon Schampijer]

Hi,

I would like to propose the following Feature for inclusion into Sugar: 
"Transfer to many" [1].


At the moment it is only possible to transfer a Journal entry to another 
learner one by one. Teachers have asked that they would like to transfer 
a file to all the class for example easily (hand out a book, assignment 
etc).


One simple idea is to add an entry to the Journal item palette that does 
a 'send-to-all friends'. The question is where to place the option in 
the palette. As the first option which might cause accidental 
triggering. Furthermore the way we handle the transfer related 
notifications in the frame should change (as described at [2]).


A long standing issue that does play into that discussion is grouping of 
learners. Currently the only option to group a number of people is to 
friend them.


Regards,
   Simon

[1] http://wiki.sugarlabs.org/go/Features/Transfer_to_many#UI_Design
[2] http://lists.sugarlabs.org/archive/sugar-devel/2011-November/034198.html
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel