[E-devel] [Annunce] E17 Trash Module + Efreet Trash Implementation
As requested per irc I have composed a new efreet patch that make the trash
implementation a separate lib (like efreet_mime is). This new patch also use
the new ecore_file_dir_is_empty(), so
you need a fresh ecore to test it.
I'm not really sure about the autotools modification I'have made... please
review it well :P
You can find the new patch attached or you can download it from:
http://www.gurumeditation.it/blog/wp-content/uploads/efreet_trash_support_02.patch
Thanks
Dave
- Dave Andreoli [EMAIL PROTECTED] ha scritto:
- Nick Hughart [EMAIL PROTECTED] ha scritto:
While this is somewhat neat, it might be best to implement this
into
efm
itself. Having it on a shelf seems a bit strange to me, but it does
make things a bit easier. The only issue I see is it requires a
dnd
and
will not come into play if something deletes a file normally in efm.
I have done the part in efreet so that we can use it in the fm
Also, I'd drop the internal dnd and just do xdnd for everything.
Since
efm supports xdnd there isn't much need to even deal with internal
dnd.
xdnd works on top of ednd, I don't know a way to use
xdnd without the e one ;)
Also, you may meet some resistance getting it into efreet. Even
though
it seems to be a haven for FDO specs, some of the authors feel it's
scope is a bit smaller then that. Just a warning :)
Anyway, this is good work and will be helpful. If there is any way
to
better tie it into efm that would be good. I believe adding items
to
the bottom of the right click context menu is possible by matching
with
a glob or mimetype. So you could just match on every file and it
would
add a Trash item to the list.
and then the fm must also show you the content of the trash. I'm
waiting
to see what append to the fm in the SoC and then we can make the fm
trash
compliant.
Dave Andreoli wrote:
HI all !
I have a new module available, it's full freedesktop.org
compliant
trash and as some cool animations.
You can download from
http://www.gurumeditation.it/blog/?page_id=90
The trash implementation is done in a clean efreet patch that is
(IMO) ready for cvs. It include also a simple URI implementation.
The module (if placed on a shelf) will accept dnd from the efm
(internal dnd) and from
any other application (xdnd). But the xdnd will not work unless
you
do at least one internal dnd (from efm or from a border). Dunno
why,
If someone have idea please let me know.
Files that are not on the local filesystem can't be trashed and
the
module will ask you if you want to delete permanently those files.
...happy testing
Dave
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: configure.in
===
RCS file: /cvs/e/e17/libs/efreet/configure.in,v
retrieving revision 1.21
diff -u -u -r1.21 configure.in
--- configure.in 19 May 2008 00:07:11 - 1.21
+++ configure.in 22 Jun 2008 19:08:20 -
@@ -1,6 +1,6 @@
rm -f config.cache
-AC_INIT(efreet, 0.5.0.043, enlightenment-devel@lists.sourceforge.net)
+AC_INIT(efreet, 0.5.0.044, enlightenment-devel@lists.sourceforge.net)
AC_PREREQ(2.52)
AC_CONFIG_SRCDIR(configure.in)
AC_CANONICAL_BUILD
@@ -69,6 +69,7 @@
efreet.spec
efreet.pc
efreet-mime.pc
+efreet-trash.pc
Makefile
src/Makefile
src/lib/Makefile
Index: efreet-trash.pc.in
===
RCS file: efreet-trash.pc.in
diff -N efreet-trash.pc.in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ efreet-trash.pc.in 22 Jun 2008 19:08:20 -
@@ -0,0 +1,11 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+Name: efreet-trash
+Description: Freedesktop Shared Trash implementation for the EFL
+Requires: @requirements@
+Version: @VERSION@
+Libs: -L${libdir} -lefreet_trash
+Cflags: -I${includedir}/efreet
Index: doc/head.html
===
RCS file: /cvs/e/e17/libs/efreet/doc/head.html,v
Re: [E-devel] E CVS: apps/e englebass
This commit has stopped all the xdnd to work both in the shelf and in the
gadcon :(
DaveMDS
- Enlightenment CVS [EMAIL PROTECTED] ha scritto:
Enlightenment CVS committal
Author : englebass
Project : e17
Module : apps/e
Dir : e17/apps/e/src/bin
Modified Files:
e_dnd.c
Log Message:
We don't need to search for window at pointer with xdnd, xdnd handles
this
already.
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_dnd.c,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -3 -r1.75 -r1.76
--- e_dnd.c 15 Jun 2008 12:19:40 - 1.75
+++ e_dnd.c 15 Jun 2008 12:28:16 - 1.76
@@ -680,12 +680,8 @@
// win = ecore_x_window_at_xy_with_skip_get(x, y, ignore_win, 2);
}
else
- /* FIXME: this is nasty. every x mouse event we go back to x and
do
- * a whole bunch of round-trips narrowing down the toplevel
window
- * which contains the mouse */
- win = ecore_x_window_shadow_tree_at_xy_with_skip_get(root, x, y,
NULL, 0);
-// win = ecore_x_window_at_xy_with_skip_get(x, y, NULL, 0);
-
+ win = root;
+
if (_drag_current)
{
_e_drag_show(_drag_current);
@@ -890,24 +886,13 @@
}
static void
-_e_drag_xdnd_end(Ecore_X_Window root, int x, int y)
+_e_drag_xdnd_end(Ecore_X_Window win, int x, int y)
{
Evas_List *l;
E_Event_Dnd_Drop ev;
int dx, dy, dw, dh;
- Ecore_X_Window win, ignore_win[2];
if (!_xdnd) return;
- if (_drag_current)
- {
- ignore_win[0] = _drag_current-evas_win;
- ignore_win[1] = _drag_win;
- win = ecore_x_window_shadow_tree_at_xy_with_skip_get(root, x, y,
ignore_win, 2);
-// win = ecore_x_window_at_xy_with_skip_get(x, y, ignore_win, 2);
- }
- else
- win = ecore_x_window_shadow_tree_at_xy_with_skip_get(root, x, y,
NULL, 0);
-// win = ecore_x_window_at_xy_with_skip_get(x, y, NULL, 0);
ev.data = _xdnd-data;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e englebass
Ok, the problem happend only when the shelf is stacked on the background.
The attached patch fix it, I'm not sure this is the right way, but seems
that _e_drag_win_matches is not needed by xdnd.
Thanks
Dave
- Dave Andreoli [EMAIL PROTECTED] ha scritto:
This commit has stopped all the xdnd to work both in the shelf and in
the gadcon :(
DaveMDS
- Enlightenment CVS [EMAIL PROTECTED] ha scritto:
Enlightenment CVS committal
Author : englebass
Project : e17
Module : apps/e
Dir : e17/apps/e/src/bin
Modified Files:
e_dnd.c
Log Message:
We don't need to search for window at pointer with xdnd, xdnd
handles
this
already.
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_dnd.c,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -3 -r1.75 -r1.76
--- e_dnd.c 15 Jun 2008 12:19:40 - 1.75
+++ e_dnd.c 15 Jun 2008 12:28:16 - 1.76
@@ -680,12 +680,8 @@
// win = ecore_x_window_at_xy_with_skip_get(x, y, ignore_win, 2);
}
else
- /* FIXME: this is nasty. every x mouse event we go back to x
and
do
- * a whole bunch of round-trips narrowing down the toplevel
window
- * which contains the mouse */
- win = ecore_x_window_shadow_tree_at_xy_with_skip_get(root, x,
y,
NULL, 0);
-// win = ecore_x_window_at_xy_with_skip_get(x, y, NULL, 0);
-
+ win = root;
+
if (_drag_current)
{
_e_drag_show(_drag_current);
@@ -890,24 +886,13 @@
}
static void
-_e_drag_xdnd_end(Ecore_X_Window root, int x, int y)
+_e_drag_xdnd_end(Ecore_X_Window win, int x, int y)
{
Evas_List *l;
E_Event_Dnd_Drop ev;
int dx, dy, dw, dh;
- Ecore_X_Window win, ignore_win[2];
if (!_xdnd) return;
- if (_drag_current)
- {
- ignore_win[0] = _drag_current-evas_win;
- ignore_win[1] = _drag_win;
- win = ecore_x_window_shadow_tree_at_xy_with_skip_get(root, x, y,
ignore_win, 2);
-// win = ecore_x_window_at_xy_with_skip_get(x, y, ignore_win, 2);
- }
- else
- win = ecore_x_window_shadow_tree_at_xy_with_skip_get(root, x,
y,
NULL, 0);
-// win = ecore_x_window_at_xy_with_skip_get(x, y, NULL, 0);
ev.data = _xdnd-data;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: e_dnd.c
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_dnd.c,v
retrieving revision 1.77
diff -u -u -r1.77 e_dnd.c
--- e_dnd.c 15 Jun 2008 12:30:26 - 1.77
+++ e_dnd.c 23 Jun 2008 13:39:51 -
@@ -752,7 +752,7 @@
move_ev.y = y - dy;
leave_ev.x = x - dx;
leave_ev.y = y - dy;
- if (E_INSIDE(x, y, dx, dy, dw, dh) _e_drag_win_matches(h, win))
+ if (E_INSIDE(x, y, dx, dy, dw, dh) /* _e_drag_win_matches(h, win)*/)
{
if (!h-entered)
{
@@ -910,8 +910,8 @@
_e_drag_coords_update(h, dx, dy, dw, dh);
ev.x = x - dx;
ev.y = y - dy;
- if (_e_drag_win_matches(h, win) h-cb.drop
- E_INSIDE(x, y, dx, dy, dw, dh))
+ if (/*_e_drag_win_matches(h, win) h-cb.drop
+ */E_INSIDE(x, y, dx, dy, dw, dh))
{
h-cb.drop(h-cb.data, h-active_type, ev);
dropped = 1;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-06-23 07:09:32 -0700
Build log for Enlightenment DR 0.17 on 2008-06-23 07:09:32 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log express http://download.enlightenment.org/tests/logs/express.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Blender fullscreen mode
blender (-w) sets _NET_WM_STATE_MAXIMIZED_VERT and _NET_WM_STATE_MAXIMIZED_HORZ (and WM_NORMAL_HINTS x,y = (0,0) w,h = (screen size)) before mapping. This might not be handled properly. /Kim Carsten Haitzler (The Rasterman) wrote: On Thu, 7 Feb 2008 20:38:07 +0100 Andreas Volz [EMAIL PROTECTED] babbled: yes. got it working. it does do slightly strange things. i have to investigate... Am Sat, 19 Jan 2008 10:37:21 +1100 schrieb Carsten Haitzler (The Rasterman): Hi, did you get your OpenGL back and were able to test Blender? regards Andreas On Sun, 30 Dec 2007 13:56:45 +0100 Andreas Volz [EMAIL PROTECTED] babbled: hmm - is blender MANUALLY resizing its window? can o0ther people reproduce? me - i just am happily having my whole xserver segv when any opengl app is run at the moment so i can;'t test until i fix this. Hello, I'm not sure if there's a bug in the E17 fullscreen policy or in Blender, so I'll ask here before filing a bug. blender --help ... Window options: -wForce opening with borders (default) -WForce opening without borders -p sx sy w h Open with lower left corner at sx, sy and width and height w, h Both options work well with other window managers (e.g. Metacity). But they both doesn't work as I expect with E17. If I use option -w it opens in a maximized window, but the window in as big as the complete screen and stays below my lower shelf. To get the desired result I need to resize the window to a small size and then maximize the window again with the maximize button. The option -W is also not working really good. The window is maximized without border, but does still stay below the bar. I know there're much possible configuration settings that influence this. But I'm very confused to finding out the correct ones. BTW: See my next mail about that topic. regards Andreas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] gnome-terminal Edit Current Profile window
Hi, yep! nice spot!!! :))) another happy same-here report. it opens on second click. weird :) Thanks, Dan Ben Martin wrote: Hi, I'm wondering if anyone else has issues opening the Edit Current Profile window of gnome-terminal when running E17? The behaviour I am getting is sometimes the properties window does not open, and when it does sometimes you can not properly manage or close it. I'm not sure what g-t would be doing that is so wonderful for this window... - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Mon, 16 Jun 2008 15:33:23 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: Hi all, I want to add crypto and signature support inside EET. This could help us provide some secure way to store password for example or the possibility to add signature to theme. The first step before doing this, is the need to agree what kind of feature we want, what will be the dependency introduced by this and if they should be optionnal. For crypto, we could have two possibilities, or we cypher the entire EET file or just an Eet_File_Node. Cyphering an entire file is perhaps not what we want, I don't thing we need to cypher all image, data and agreed. if you want whole-file encryption i am sure there are more transparent ways to get it (a vfs layer for examlpe). one day streams. I believe that just cyphering an Eet_File_Node is enough. We have still 31 bits available in the flags field. We could use 8bits of this field to define a key index that will be provide at run time to the right Eet_File. For this we will need the following API : EAPI Eet_Key *eet_crypt_key_new(const char *key); EAPI void eet_crypt_key_free(Eet_Key *key); EAPI int eet_crypt_key_define(Eet_File *ef, Eet_Key *key, unsigned char index); EAPI int eet_crypt_key_set(Eet_File *ef, const char *name, unsigned char index); EAPI int eet_crypt_key_get(Eet_File *ef, const char *name); I think we could also provide : EAPI void *eet_crypt_data(Eet_Key *key, void *data, int length); EAPI void *eet_uncrypt_data(Eet_Key *key, void *data, int length); and manipulate cyphered eet data. Now for signature support, I think we don't need to sign per Eet_File_Node, but only for the eet file. On this topic I don't know if we need to have our own way of signing our data (adding signature a bunch of signature at the end of the eet file or if we should use any known schem. Perhaps it depend on the crypto library we decide to use. i can't much comment - i'm no expert on this :( it's a subject area i have never really paid much attention to. On this topic, I believe we have two choice, libtomcrypt (http://libtom.org/?page=featuresnewsitems=5whatfile=crypt) and openssl. My opinion on this subject is certainly biased as I already use libtomcrypt, but it's a small, simple and easy to port library. I believe we should make this dependency optional (if eet is compiled without crypto support all function call requiring it will just cleanly fail). agree with it being optional. agree with them failing if not compiled in. i lean to openssl myself - or even gnutls. i know little of libmcrypt. as above. i'm no expert. what i will say. the whole key index thing looks odd to me. we are going to just deal with tiny bits of encrypted data here, so efficiency is not so important. why not simply provide a simplistic EAPI void *eet_crypt_read(Eet_File *ef, const char *name, const char *key, int *size_ret); EAPI int eet_crypt_write(Eet_File *ef, const char *name, const char *key, const void *data, int size, int compress); ? as such the data is encrypted given a specific passphrase/key and stored. that key is needed for decryption (if not given - we can either return NUL or just garbage. up to us). the important bits here are that without the key - the item cannot (sanely) be decrypted. (sure given 192332 years and enough compute power to run that long...). so from the key you generate a salt and then encode/decode with that. the important bit is making sure that key is not left around anywhere. any copies of it in ram are nulled out as soon as they are not used anymore etc. etc. - at least as far as eet is concerned. null out any useful intermediate data too. i dont see why we need to go define limited fixed set of keys per file? just provide the key on read/write? So guys, what's your opinion on this subject ? -- Cedric BAIL - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] gnome-terminal Edit Current Profile window
On Sun, 15 Jun 2008 20:51:59 +1000 Ben Martin [EMAIL PROTECTED] babbled: Hi, I'm wondering if anyone else has issues opening the Edit Current Profile window of gnome-terminal when running E17? The behaviour I am getting is sometimes the properties window does not open, and when it does sometimes you can not properly manage or close it. I'm not sure what g-t would be doing that is so wonderful for this window... works reliably for me all the time? :/ -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 02:32:22AM +1000, Carsten Haitzler wrote: On Mon, 16 Jun 2008 15:33:23 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: Hi all, I want to add crypto and signature support inside EET. This could help us provide some secure way to store password for example or the possibility to add signature to theme. The first step before doing this, is the need to agree what kind of feature we want, what will be the dependency introduced by this and if they should be optionnal. For crypto, we could have two possibilities, or we cypher the entire EET file or just an Eet_File_Node. Cyphering an entire file is perhaps not what we want, I don't thing we need to cypher all image, data and agreed. if you want whole-file encryption i am sure there are more transparent ways to get it (a vfs layer for examlpe). one day streams. I believe that just cyphering an Eet_File_Node is enough. We have still 31 bits available in the flags field. We could use 8bits of this field to define a key index that will be provide at run time to the right Eet_File. For this we will need the following API : EAPI Eet_Key *eet_crypt_key_new(const char *key); EAPI void eet_crypt_key_free(Eet_Key *key); EAPI int eet_crypt_key_define(Eet_File *ef, Eet_Key *key, unsigned char index); EAPI int eet_crypt_key_set(Eet_File *ef, const char *name, unsigned char index); EAPI int eet_crypt_key_get(Eet_File *ef, const char *name); I think we could also provide : EAPI void *eet_crypt_data(Eet_Key *key, void *data, int length); EAPI void *eet_uncrypt_data(Eet_Key *key, void *data, int length); and manipulate cyphered eet data. Now for signature support, I think we don't need to sign per Eet_File_Node, but only for the eet file. On this topic I don't know if we need to have our own way of signing our data (adding signature a bunch of signature at the end of the eet file or if we should use any known schem. Perhaps it depend on the crypto library we decide to use. i can't much comment - i'm no expert on this :( it's a subject area i have never really paid much attention to. On this topic, I believe we have two choice, libtomcrypt (http://libtom.org/?page=featuresnewsitems=5whatfile=crypt) and openssl. My opinion on this subject is certainly biased as I already use libtomcrypt, but it's a small, simple and easy to port library. I believe we should make this dependency optional (if eet is compiled without crypto support all function call requiring it will just cleanly fail). agree with it being optional. agree with them failing if not compiled in. i lean to openssl myself - or even gnutls. i know little of libmcrypt. as above. i'm no expert. what i will say. the whole key index thing looks odd to me. we are going to just deal with tiny bits of encrypted data here, so efficiency is not so important. why not simply provide a simplistic EAPI void *eet_crypt_read(Eet_File *ef, const char *name, const char *key, int *size_ret); EAPI int eet_crypt_write(Eet_File *ef, const char *name, const char *key, const void *data, int size, int compress); ? as such the data is encrypted given a specific passphrase/key and stored. that key is needed for decryption (if not given - we can either return NUL or just garbage. up to us). the important bits here are that without the key - the item cannot (sanely) be decrypted. (sure given 192332 years and enough compute power to run that long...). so from the key you generate a salt and then encode/decode with that. the important bit is making sure that key is not left around anywhere. any copies of it in ram are nulled out as soon as they are not used anymore etc. etc. - at least as far as eet is concerned. null out any useful intermediate data too. i dont see why we need to go define limited fixed set of keys per file? just provide the key on read/write? I'm not exactly sure what you are planing to push into and pull out of this API, but it might be more sensible to provide the key on open. And then use a scheme like CBC to encode a stream of data until it is done. Then close. Or in other words; start(); add_data()...; finish(); Having a pool of registered keys might make sense if it is envisaged that more than one might be used at a time - though not on the same set of data. With regards do zeroing RAM, that is a good idea. But its really all a bit moot if the memory is swappable. So guys, what's your opinion on this subject ? -- Cedric BAIL - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list
Re: [E-devel] gnome-terminal Edit Current Profile window
On Tue, 2008-06-24 at 02:33 +1000, Carsten Haitzler wrote: On Sun, 15 Jun 2008 20:51:59 +1000 Ben Martin [EMAIL PROTECTED] babbled: Hi, I'm wondering if anyone else has issues opening the Edit Current Profile window of gnome-terminal when running E17? The behaviour I am getting is sometimes the properties window does not open, and when it does sometimes you can not properly manage or close it. I'm not sure what g-t would be doing that is so wonderful for this window... works reliably for me all the time? :/ $ rpm -qf /usr/bin/gnome-terminal gnome-terminal-2.22.2-1.fc9.x86_64 e17 version 0.16.990.043 (from about dialog) pulled from cvs.enlightenment.org:/cvs/e signature.asc Description: This is a digitally signed message part - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: I'm not exactly sure what you are planing to push into and pull out of this API, but it might be more sensible to provide the key on open. And then use a scheme like CBC to encode a stream of data until it is done. Then close. Or in other words; start(); add_data()...; finish(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? Having a pool of registered keys might make sense if it is envisaged that more than one might be used at a time - though not on the same set of data. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) With regards do zeroing RAM, that is a good idea. But its really all a bit moot if the memory is swappable. sure - though as such it would massively reduce the likelihood of inadvertent passkey trails in core dumps etc. swap we can't do anything about - but if you copy the key, use it and derivative data really fast them nuke everything chances of it being found later by mistake are lower. it's definitely not a solution, but a risk mitigation at any rate. if you have access to the memory space of a process to be able to do this it's normally game over anyway, but there is not much we can do there beyond mlock()... and then we're in root-only land. So guys, what's your opinion on this subject ? -- Cedric BAIL - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
