Hello for everyone,
Some days ago I've used your os (Sculpt v.20.08) from bootable usb and I remained genuinely impressed regarding its style and its security base idea, after having read some informations on it, I was able to develop some tips which I would like to share with the community:
======================= Language Compatibility =======================
*) there is no support for Italian keyboard, I was able to find only german, french and english .chargen files, for a next update would be great to add other charger files.
*) I can give my full support for translating document pages in Italian, this could (apparently) be great for increasing the possible audience, but Honestly I doubt that an Italian community could be created (we are quite far in the security-technological field, No comment on that, please).
======================= BEGINNER FRIENDLY OS? =======================
*) I know that this operating system is not developed to be user friendly, but it could be great to put some helps for beginners, like a graphical instruction box when clicking on certain things in Leitzentrale, a graphical example could be the following:
|------------| |-------| | depot | (when clicking on it appears an info box) --> | info | |_______| |-------|
(sorry for the bad ASCII image)
======================= GRAPHICS =======================
*) Probably the best point for your os consists on its graph graphics, the idea of Leitzentrale is innovative if we confront it to Windows os or similar, a small hint could be to create the same style for the "file" part, so something which could be similar to graphviz2 output instead of "block representation".
{
direct link to my idea: https://graphviz-perl.github.io/
see the graph under the "Input file # 17 - t/gen.parse.stt.t" example,
s/other_names/folder_names/g
}
*) small consideration: I find some graphical glitch in the "motif decoration" 's node in Leitzentrale (it flew up and down without any input) [Still studying this..]
======================== DOCUMENTATIONS ========================
*)Your site is pretty cool and interesting, documentation is great but I haven't seen anything on Sculpt, could be great to add like UNIX's manpages system.
========================= WIRELESS SUBSYSTEM =========================
*) I asked for the documentation on it before speaking (Thanks Alexander), it is extremely similar to Linux wireless subsystem, except for a modified libnl support for user space, could I have the source code for it? I would like to study the modification you've apported for libnl. I am pretty fascinated by those modified subsystems.
*) It would be great to extend the range for other devices, I saw you implemented only the iwlwifi driver, would be great to implement also brcmf (both HardMac and SoftMac) and even Qualcomm's wireless card, I can give my full support for that.
/* *) I have some ideas for controlling the iwlwifi blob, for now I would like to test it on my own, in general it would be great to ""customize"" the "blob loading". */
======================== Custom Patching system ========================
*) I've seen the potential of the software based hardware management, my biggest hint should be to implement a security patching system with a similar interface to Depot (something like: choose customization part, insert code patch [like linux's kernel system] and process it) | V could be a dangerous door for local-cyber-attacks
======================== TERMINAL DOWNSIDE ========================
*) Using the inspect shell I wasn't able to scroll up, do you know if it's implemented? It should be better to have a scroll bar,
======================= DEPOT SYSTEM =======================
As I understood, depot is like a package manager and the various repositories contains various applications, Here I'll insert my ideas on it:
*) Many of those repos are inaccessible even if I am connected to the wireless network:
{ I am not able to download/fetch the following repos: [-] ehmry [-] blarson [-] rite }
*) in general there isn't much variety in the repos, many packages are the same, it would be great to extend the "candidates" list, I can contribute to the development of several CLI apps.
*) I can work for inserting some scripting languages interpreter packages inside Genode
{ [-] Minised [-] lightweight Perl languages (microperl, miniperl or my customized languages) } and maybe adapt them for the OS needs and tasks.
*) A quite interesting idea would be to add local depots, In general:
-->) We have 2 devices, (featured phones or similar) -->) The first is the client, the second is the depot server -->) through Bluetooth, BLE or even other standards (nfc??) could be cool to use the repository stored in the second phone into the first.
[ Obviously this is extremely complex to do: we should set a correct cryptographic key exchange and set an authentication rule, this could lead an ∞ of problems:
*) Hijacking or other Bluetooth attacks are possible, the worst case scenario is that an untrusted depot server can inject the device, bypassing the security authentication restriction. If this will be implemented, it MUST be well structured.
*) Not every device has the same bluetooth version, with some works it could be implemented a workaround which act like a switch statement:
{ example: switch(bluetooth_version){ case (version == 5.0 ) {do this} case (version == 4.1 ) {do that} } }
*) Obviously it must be implemented a tiny bluetooth subsystem, I suggest using Linux's one. (I have also the 2008-2009 documentation on it).
*) This idea could be a great topic for your blog, I can help with the formal verifications (pi calculus?) exposition and with other implementation details.
]
I have many other ideas, These are some "fast" considerations for improve the OS quality, my "knowledge CV" is here: (https://github.com/Baseband-processor)
Let me know if you have some doubt, Regards and Thanks for you work,
Edoardo Mantovani, 2021
Hello Edoardo,
========================= WIRELESS SUBSYSTEM =========================
*) I asked for the documentation on it before speaking (Thanks Alexander), it is extremely similar to Linux wireless subsystem, except for a modified libnl support for user space, could I have the source code for it? I would like to study the modification you've apported for libnl. I am pretty fascinated by those modified subsystems.
You can find all modifications in Genode's git repository in the 'dde_linux' repo [1], in particular 'src/lib/libnl'. The 14.11 [2] release-notes contain an overview of the architecture of the 'wifi_drv' component. Although some things are different by now the overall picture is similar.
[1] https://github.com/genodelabs/genode/tree/master/repos/dde_linux [2] https://genode.org/documentation/release-notes/14.11#Intel_wireless_stack
*) It would be great to extend the range for other devices, I saw you implemented only the iwlwifi driver, would be great to implement also brcmf (both HardMac and SoftMac) and even Qualcomm's wireless card, I can give my full support for that.
Having support for more/different wireless devices is certainly useful and at some point necessary. If you would like to join this effort, I can give you some hints on where or how to start.
/* *) I have some ideas for controlling the iwlwifi blob, for now I would like to test it on my own, in general it would be great to ""customize"" the "blob loading". */
If you look into 'repos/dde_linux/src/lib/wifi/firmware.cc' you will see that the firmware blobs are simply requested via a ROM session. With some tinkering in Sculpt you could set the system up in a way that it becomes possible to load the firmware-images differently.
Regards Josef
BEGINNER FRIENDLY OS?
*) I know that this operating system is not developed to be user friendly, but it could be great to put some helps for beginners, like a graphical instruction box when clicking on certain things in Leitzentrale, a graphical example could be the following:
|------------| |-------| | depot | (when clicking on it appears an info box) --> | info | |_______| |-------|
(sorry for the bad ASCII image)
Can't contribute much or at all for the rest, but here's my 2 cents on app discovery and inline help : in my apps I provide a thin text-field (one-liner label with reduced font size) at the bottom of all windows, and change the text dynamically when the mouse pointer hovers over various buttons or menus or whichever widget.
Something similar occurs in a web browser, but only when you hover above a URL, so much less useful. From my memories of using MS Word a few centuries ago I think it provded something similar too, though restricted to menu items, not toolbar buttons.
The alternative is to use tool-tips, but I'm not a big fan of those (the short delay before a tooltip appears is too long when you actually want to explore/discover the UI, and too short when you don't ; by contrast, my scheme is instant when you need it, and does not get in the way when you don't look at it).
Cedric
Hiello,
That's great, but my ideas target directly the os implementation, I was thinking to embed the tool-tip into the node "focus" code for leveraging the delay (maybe the option can be deactivated from an "options launcher").
Your scheme also seems interesting to me, but think that I am not so expert in GUI programming, those were only some of my thoughts.
Regards, Edoardo Mantovani, 2021
Il giorno sab 23 gen 2021 alle ore 16:43 ttcoder@netcourrier.com ha scritto:
BEGINNER FRIENDLY OS?
*) I know that this operating system is not developed to be user friendly, but it could be great to put some helps for beginners, like a graphical instruction box when clicking on certain things in Leitzentrale, a graphical example could be the following:
|------------| |-------| | depot | (when clicking on it appears an info box) --> | info | |_______| |-------|
(sorry for the bad ASCII image)
Can't contribute much or at all for the rest, but here's my 2 cents on app discovery and inline help : in my apps I provide a thin text-field (one-liner label with reduced font size) at the bottom of all windows, and change the text dynamically when the mouse pointer hovers over various buttons or menus or whichever widget.
Something similar occurs in a web browser, but only when you hover above a URL, so much less useful. From my memories of using MS Word a few centuries ago I think it provded something similar too, though restricted to menu items, not toolbar buttons.
The alternative is to use tool-tips, but I'm not a big fan of those (the short delay before a tooltip appears is too long when you actually want to explore/discover the UI, and too short when you don't ; by contrast, my scheme is instant when you need it, and does not get in the way when you don't look at it).
Cedric
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Edoardo,
thanks for your feedback on Sculpt OS!
======================= Language Compatibility =======================
*) there is no support for Italian keyboard, I was able to find only german, french and english .chargen files, for a next update would be great to add other charger files.
You may find our xkb2ifcfg tool [1] useful as a starting point. I'd welcome a patch with a known-to-work chargen file for Italian keyboards.
[1] https://genode.org/documentation/release-notes/19.08#Flexible_keyboard_layou...
*) I can give my full support for translating document pages in Italian, this could (apparently) be great for increasing the possible audience, but Honestly I doubt that an Italian community could be created (we are quite far in the security-technological field, No comment on that, please).
Thank you for the offer, but intuitively I share your doubts.
For the highly technical target audience of Genode and Sculpt OS, I think it should be ok to assume English reading skills. Note that - even though most Genode developers are German - we don't offer German documentation either.
That being said, I don't want to keep you back from hosting and supporting an Italian edition of Sculpt OS.
======================= BEGINNER FRIENDLY OS? =======================
*) I know that this operating system is not developed to be user friendly, but it could be great to put some helps for beginners, like a graphical instruction box when clicking on certain things in Leitzentrale, a graphical example could be the following:
|------------| |-------| | depot | (when clicking on it appears an info box) --> | info | |_______| |-------|
(sorry for the bad ASCII image)
I actually intended adding such a context-sensitive help feature along with other usability improvements such as keyboard navigation, but I haven't made it a priority for now. Let's face it: there is no way to appreciate Sculpt without at least reading the documentation. Adding some hints here and there would just pretend otherwise. Making the UI fully discoverable without the need to read the manual would certainly be cool but it would be a tremendous effort. I think other topics are more worthwhile to focus on (https://genode.org/about/road-map).
======================= GRAPHICS =======================
*) Probably the best point for your os consists on its graph graphics, the idea of Leitzentrale is innovative if we confront it to Windows os or similar, a small hint could be to create the same style for the "file" part, so something which could be similar to graphviz2 output instead of "block representation".
With the nice implementation of the graph in place, this was indeed tempting. I still decided against its use for files for the following reasons:
- Giving each tab a distinct appearance avoids mixing things up. The files tab is unrelated to the component graph. Unrelated things should better not look similar.
- Whereas the component graph is interesting due to the transitive dependencies, especially when clicking on a component that uses many services, a file graph 1ooks boring because each file has merely one parent. So the graph would not be able to shine with its beauty anyway.
- The number of components is relatively low compared to the typical number of files present in a directory. So a file graph would probably become a noisy mess. I'm afraid it would look forced.
However, if you have ideas, please don't hesitate to try them out! I'd love to play with alternatives. Maybe, you could consider providing an experimental file browser as an installable package to let others like me evaluate your ideas?
*) small consideration: I find some graphical glitch in the "motif decoration" 's node in Leitzentrale (it flew up and down without any input) [Still studying this..]
If you have instructions to reproduce the issue, this would be very much appreciated.
As far as I am aware, such glitches can happen whenever a component has a dangling route. E.g., when killing a server that still has clients, the sessions of its former clients are going to nowhere. Such a client's graph node tends to behave a bit "erratic" in this situation.
======================== TERMINAL DOWNSIDE ========================
*) Using the inspect shell I wasn't able to scroll up, do you know if it's implemented? It should be better to have a scroll bar,
That's not implemented. The inspect shell will be removed at some point. Once the file browser will able to perform basic file operations like copying or renaming files, we can drop the inspect tab. See [2] for the bigger picture.
[2] https://genode.org/documentation/release-notes/20.02#Redesign_of_the_adminis...
For getting work done in the terminal, I think we should ultimately enable a feature-rich existing terminal implementation as a package. E.g., a port of a terminal based on the QTerminal widget.
[3] https://github.com/lxqt/qtermwidget
======================= DEPOT SYSTEM =======================
As I understood, depot is like a package manager and the various repositories contains various applications, Here I'll insert my ideas on it:
*) Many of those repos are inaccessible even if I am connected to the wireless network:
{ I am not able to download/fetch the following repos: [-] ehmry [-] blarson [-] rite }
*) in general there isn't much variety in the repos, many packages are the same, it would be great to extend the "candidates" list, I can contribute to the development of several CLI apps.
The list of candidates is simply generated from the public keys registered at [4]. I agree that the solution is quite poor because a user cannot really know what's behind all these strange names. If you take the articles at https://genodians.org as context into account, it makes a bit more sense because you can then draw the connections between authors and their depots. So if a developer like alex-ab publishes an article, you can follow his steps by fetching alex-ab's packages.
[4] https://github.com/genodelabs/genode/tree/master/depot
On the other hand, as you noticed, not all developers who have registered their public keys actually provide packages. So the user experience from a discoverability view point is rather poor. Maybe it would be better to remove most of the keys and implement a key-sharing feature so that one developer can ship the keys of other developers along with short descriptions about who is who, similar to a web of trust?
Anyway, if you like to be featured in the depot selection of the next release, please do not hesitate to issue a pull request with your public key and download location. Just follow the lines of the existing entries at [4].
*) I can work for inserting some scripting languages interpreter packages inside Genode
{ [-] Minised [-] lightweight Perl languages (microperl, miniperl or my customized languages) } and maybe adapt them for the OS needs and tasks.
That sounds cool. While being on the topic of porting software, let me point you to the Goa tool [5], which is geared to such work. I recommend following the article series by using the link at the bottom of each posting.
[5] https://genodians.org/nfeske/2019-11-25-goa
*) A quite interesting idea would be to add local depots, In general:
-->) We have 2 devices, (featured phones or similar) -->) The first is the client, the second is the depot server -->) through Bluetooth, BLE or even other standards (nfc??) could be cool to use the repository stored in the second phone into the first.
[ Obviously this is extremely complex to do: we should set a correct cryptographic key exchange and set an authentication rule, this could lead an ∞ of problems:
*) Hijacking or other Bluetooth attacks are possible, the worst case scenario is that an untrusted depot server can inject the device, bypassing the security authentication restriction. If this will be implemented, it MUST be well structured.
*) Not every device has the same bluetooth version, with some works it could be implemented a workaround which act like a switch statement:
{ example: switch(bluetooth_version){ case (version == 5.0 ) {do this} case (version == 4.1 ) {do that} } }
*) Obviously it must be implemented a tiny bluetooth subsystem, I suggest using Linux's one. (I have also the 2008-2009 documentation on it).
*) This idea could be a great topic for your blog, I can help with the formal verifications (pi calculus?) exposition and with other implementation details.
]
I'm afraid you lost me a little on this topic. ;-)
However, if you are speaking of a "local depot" as means to have a nested Sculpt system where a subsystem uses a different depot, that should be feasible. Should you want experimenting in this direction, you may find the depot_download and depot_deploy subsystems and their accompanied run scripts [6,7] useful to look at.
[6] https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_deploy... [7] https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_downlo...
Cheers Norman
Thanks Norman and thanks Josef for the documentation,
I'll work on my ideas in the next few days, I'll put you at the current as soon as I can .
Regards, Edoardo Mantovani
Il giorno lun 25 gen 2021 alle ore 14:38 Norman Feske norman.feske@genode-labs.com ha scritto:
Hello Edoardo,
thanks for your feedback on Sculpt OS!
======================= Language Compatibility =======================
*) there is no support for Italian keyboard, I was able to find only german, french and english .chargen files, for a next update would be great to add other charger files.
You may find our xkb2ifcfg tool [1] useful as a starting point. I'd welcome a patch with a known-to-work chargen file for Italian keyboards.
[1] https://genode.org/documentation/release-notes/19.08#Flexible_keyboard_layou...
*) I can give my full support for translating document pages in Italian, this could (apparently) be great for increasing the possible audience, but Honestly I doubt that an Italian community could be created (we are quite far in the security-technological field, No comment on that, please).
Thank you for the offer, but intuitively I share your doubts.
For the highly technical target audience of Genode and Sculpt OS, I think it should be ok to assume English reading skills. Note that - even though most Genode developers are German - we don't offer German documentation either.
That being said, I don't want to keep you back from hosting and supporting an Italian edition of Sculpt OS.
======================= BEGINNER FRIENDLY OS? =======================
*) I know that this operating system is not developed to be user friendly, but it could be great to put some helps for beginners, like a graphical instruction box when clicking on certain things in Leitzentrale, a graphical example could be the following:
|------------| |-------| | depot | (when clicking on it appears an info box) --> | info | |_______| |-------|
(sorry for the bad ASCII image)
I actually intended adding such a context-sensitive help feature along with other usability improvements such as keyboard navigation, but I haven't made it a priority for now. Let's face it: there is no way to appreciate Sculpt without at least reading the documentation. Adding some hints here and there would just pretend otherwise. Making the UI fully discoverable without the need to read the manual would certainly be cool but it would be a tremendous effort. I think other topics are more worthwhile to focus on (https://genode.org/about/road-map).
======================= GRAPHICS =======================
*) Probably the best point for your os consists on its graph graphics, the idea of Leitzentrale is innovative if we confront it to Windows os or similar, a small hint could be to create the same style for the "file" part, so something which could be similar to graphviz2 output instead of "block representation".
With the nice implementation of the graph in place, this was indeed tempting. I still decided against its use for files for the following reasons:
Giving each tab a distinct appearance avoids mixing things up. The files tab is unrelated to the component graph. Unrelated things should better not look similar.
Whereas the component graph is interesting due to the transitive dependencies, especially when clicking on a component that uses many services, a file graph 1ooks boring because each file has merely one parent. So the graph would not be able to shine with its beauty anyway.
The number of components is relatively low compared to the typical number of files present in a directory. So a file graph would probably become a noisy mess. I'm afraid it would look forced.
However, if you have ideas, please don't hesitate to try them out! I'd love to play with alternatives. Maybe, you could consider providing an experimental file browser as an installable package to let others like me evaluate your ideas?
*) small consideration: I find some graphical glitch in the "motif decoration" 's node in Leitzentrale (it flew up and down without any input) [Still studying this..]
If you have instructions to reproduce the issue, this would be very much appreciated.
As far as I am aware, such glitches can happen whenever a component has a dangling route. E.g., when killing a server that still has clients, the sessions of its former clients are going to nowhere. Such a client's graph node tends to behave a bit "erratic" in this situation.
======================== TERMINAL DOWNSIDE ========================
*) Using the inspect shell I wasn't able to scroll up, do you know if it's implemented? It should be better to have a scroll bar,
That's not implemented. The inspect shell will be removed at some point. Once the file browser will able to perform basic file operations like copying or renaming files, we can drop the inspect tab. See [2] for the bigger picture.
[2] https://genode.org/documentation/release-notes/20.02#Redesign_of_the_adminis...
For getting work done in the terminal, I think we should ultimately enable a feature-rich existing terminal implementation as a package. E.g., a port of a terminal based on the QTerminal widget.
[3] https://github.com/lxqt/qtermwidget
======================= DEPOT SYSTEM =======================
As I understood, depot is like a package manager and the various repositories contains various applications, Here I'll insert my ideas on it:
*) Many of those repos are inaccessible even if I am connected to the wireless network:
{ I am not able to download/fetch the following repos: [-] ehmry [-] blarson [-] rite }
*) in general there isn't much variety in the repos, many packages are the same, it would be great to extend the "candidates" list, I can contribute to the development of several CLI apps.
The list of candidates is simply generated from the public keys registered at [4]. I agree that the solution is quite poor because a user cannot really know what's behind all these strange names. If you take the articles at https://genodians.org as context into account, it makes a bit more sense because you can then draw the connections between authors and their depots. So if a developer like alex-ab publishes an article, you can follow his steps by fetching alex-ab's packages.
[4] https://github.com/genodelabs/genode/tree/master/depot
On the other hand, as you noticed, not all developers who have registered their public keys actually provide packages. So the user experience from a discoverability view point is rather poor. Maybe it would be better to remove most of the keys and implement a key-sharing feature so that one developer can ship the keys of other developers along with short descriptions about who is who, similar to a web of trust?
Anyway, if you like to be featured in the depot selection of the next release, please do not hesitate to issue a pull request with your public key and download location. Just follow the lines of the existing entries at [4].
*) I can work for inserting some scripting languages interpreter packages inside Genode
{ [-] Minised [-] lightweight Perl languages (microperl, miniperl or my customized languages) } and maybe adapt them for the OS needs and tasks.
That sounds cool. While being on the topic of porting software, let me point you to the Goa tool [5], which is geared to such work. I recommend following the article series by using the link at the bottom of each posting.
[5] https://genodians.org/nfeske/2019-11-25-goa
*) A quite interesting idea would be to add local depots, In general:
-->) We have 2 devices, (featured phones or similar) -->) The first is the client, the second is the depot server -->) through Bluetooth, BLE or even other standards (nfc??) could be cool to use the repository stored in the second phone into the first.
[ Obviously this is extremely complex to do: we should set a correct cryptographic key exchange and set an authentication rule, this could lead an ∞ of problems:
*) Hijacking or other Bluetooth attacks are possible, the worst case scenario is that an untrusted depot server can inject the device, bypassing the security authentication restriction. If this will be implemented, it MUST be well structured.
*) Not every device has the same bluetooth version, with some works it could be implemented a workaround which act like a switch statement:
{ example: switch(bluetooth_version){ case (version == 5.0 ) {do this} case (version == 4.1 ) {do that} } }
*) Obviously it must be implemented a tiny bluetooth subsystem, I suggest using Linux's one. (I have also the 2008-2009 documentation on it).
*) This idea could be a great topic for your blog, I can help with the formal verifications (pi calculus?) exposition and with other implementation details.
]
I'm afraid you lost me a little on this topic. ;-)
However, if you are speaking of a "local depot" as means to have a nested Sculpt system where a subsystem uses a different depot, that should be feasible. Should you want experimenting in this direction, you may find the depot_download and depot_deploy subsystems and their accompanied run scripts [6,7] useful to look at.
[6] https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_deploy... [7] https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_downlo...
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Eduardo,
Thanks for the detailed and helpful feedback, and especially for your disposition to contribute to the project! There was already a lot of feedback to your mail, but please let me add another idea regarding language compatibility.
El 22.01.21 a las 12:26, Edoardo Mantovani escribió:
======================= Language Compatibility =======================
*) there is no support for Italian keyboard, I was able to find only german, french and english .chargen files, for a next update would be great to add other charger files.
*) I can give my full support for translating document pages in Italian, this could (apparently) be great for increasing the possible audience, but Honestly I doubt that an Italian community could be created (we are quite far in the security-technological field, No comment on that, please).
Some years ago, we started pushing the documentation of the Genode and Sculpt in the Wikipedia. Today the Genode/Sculpt article already exists in 6 very different languages and we're happy not only about the sheer number but even more about the fact that most of these articles were written by community members from around the world.
However, so far, there is no Italian version of the article. If fixing this would be of interest for you, I'd be more than happy to help you wherever I can. A good reference would be the English version as it is the most elaborated one. What do you think?
Best regards, Martin
Hello everyone,
As a first point, I want to apologise for the retard of my email, cause school in those days I wasn't able to work full time to your project, as soon as I can, I'll try to remedy that by showing off some of my other ideas.
1) Thanks for your reply Martin, is this the page you intended? https://en.wikipedia.org/wiki/Genode, if yes, don't worry, I've already started the translation, I'll send the transcript to you for the publication on Wikipedia.
2) Norman, as already mentioned I wasn't able to build my microsed interpreter using Genode's libc, as reference I'll attach a naive version of microsed, with few modifications from the original minised project, I am still trying to insert the exceptional "exec" keyword, which handles Genode's based System calls, Could I know if the Genode's libc version support the homonymun function exec? I haven't still tried it yet! Could I also have general feedback on this? persists still some bugs (as the -e flag which causes an instant core dump) but I am working for fixing those issues, The real power up is in the size and speed optimization.
{ SHA512 of microsed: 8b863900afe6f044cc6b33291fcf0630da444916104db24a97dc628dc687841b14fe1260813d7beb6dcd9da4dbfd9805a67764a67de6218ebf046c0a270c40a6 }
3) Regarding to the last part of my first post, I want to explain again the idea of a new depot system, based on PANs which works as follow: - 1] in this initial situation, consider 2 devices: A and B, in one of those there is installed the Genode os (Sculpt in our case, this is the device A) while the device B has installed a "server" application, so B can have linux/Windows/Macos ecc.. but with an official Genode server app. - 2] Now let's figure out that B want to offer to A a customized package, the user of the device A can set up an automatic live Depot search which involves the use of bluetooth (or any general near field communication structure) for scanning the nearest depot servers (device B), now, if the device A choose the respective device B, it starts a key exchange communication where, at the end, if the device B is authenticated, the device A can see and install the device's B packages through the normal Depot system. This idea could be great for portable and embedded devices but, as obvious, new vulnerability issues will be born.
PS: İ've read some articles on your site, could I know if you already use a fuzzing system for verifying the presence of bugs in Sculpt os ? This can be an interesting topic for future articles, as soon I can I'll experiment something similar.
Let me know your ideas!
Regards, Edoardo Mantovani, 2020
Il giorno mar 2 feb 2021 alle ore 09:02 Martin Stein < martin.stein@genode-labs.com> ha scritto:
Hi Eduardo,
Thanks for the detailed and helpful feedback, and especially for your disposition to contribute to the project! There was already a lot of feedback to your mail, but please let me add another idea regarding language compatibility.
El 22.01.21 a las 12:26, Edoardo Mantovani escribió:
======================= Language Compatibility =======================
*) there is no support for Italian keyboard, I was able to find only german, french and english .chargen files, for a next update would be great to add other charger files.
*) I can give my full support for translating document pages in Italian, this could (apparently) be great for increasing the possible audience, but Honestly I doubt that an Italian community could be created (we are quite far in the security-technological field, No comment on that, please).
Some years ago, we started pushing the documentation of the Genode and Sculpt in the Wikipedia. Today the Genode/Sculpt article already exists in 6 very different languages and we're happy not only about the sheer number but even more about the fact that most of these articles were written by community members from around the world.
However, so far, there is no Italian version of the article. If fixing this would be of interest for you, I'd be more than happy to help you wherever I can. A good reference would be the English version as it is the most elaborated one. What do you think?
Best regards, Martin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Edoardo,
I just noticed that I misspelled your first name in my reply mail. Sorry for that!
- Thanks for your reply Martin, is this the page you intended?
https://en.wikipedia.org/wiki/Genode, if yes, don't worry, I've already started the translation, I'll send the transcript to you for the publication on Wikipedia.
Wow, that was fast :) I'm glad you liked my proposal and am looking forward to read your text (I'm not good at all but do understand some basics in Italian). If there's anything around the article where I could be of help, just say so.
Cheers, Martin
Hi Edoardo,
- Norman, as already mentioned I wasn't able to build my microsed
interpreter using Genode's libc, as reference I'll attach a naive version of microsed, with few modifications from the original minised project, I am still trying to insert the exceptional "exec" keyword, which handles Genode's based System calls, Could I know if the Genode's libc version support the homonymun function exec? I haven't still tried it yet! Could I also have general feedback on this? persists still some bugs (as the -e flag which causes an instant core dump) but I am working for fixing those issues, The real power up is in the size and speed optimization.
{ SHA512 of microsed: 8b863900afe6f044cc6b33291fcf0630da444916104db24a97dc628dc687841b14fe1260813d7beb6dcd9da4dbfd9805a67764a67de6218ebf046c0a270c40a6 }
I'm afraid that I am not able to help you out here. There seems to be no way around manual instrumenting and debugging.
For getting feedback, you may consider linking to a publicly accessible Git branch of your work, e.g., via GitHub. I think that I'm not alone with my hesitation to dig into a zip file that comes attached to a mailing-list posting. Providing a link to a branch is a great way to avoid such friction.
- Regarding to the last part of my first post, I want to explain again
the idea of a new depot system, based on PANs which works as follow: - 1] in this initial situation, consider 2 devices: A and B, in one of those there is installed the Genode os (Sculpt in our case, this is the device A) while the device B has installed a "server" application, so B can have linux/Windows/Macos ecc.. but with an official Genode server app. - 2] Now let's figure out that B want to offer to A a customized package, the user of the device A can set up an automatic live Depot search which involves the use of bluetooth (or any general near field communication structure) for scanning the nearest depot servers (device B), now, if the device A choose the respective device B, it starts a key exchange communication where, at the end, if the device B is authenticated, the device A can see and install the device's B packages through the normal Depot system. This idea could be great for portable and embedded devices but, as obvious, new vulnerability issues will be born.
Except for the bluetooth part, I somehow fail to see the difference from the existing depot mechanism.
I wonder, what distinguishes e.g., the server that hosts https://depot.genode.org from your device B?
The discovery part seems to be roughly covered by the index files, e.g., https://depot.genode.org/nfeske/index/, which are the basis for the depot-selection menu structures of Sculpt OS.
Doesn't the remaining part of your picture comes down to tunneling TCP/IP (for https) over a bluetooth connection or mesh network? Admittedly, I'm not well versed in this area.
I think security is not an issue because the depot mechanism does not trust the network infrastructure and the depot server infrastructure anyway. The end-to-end integrity of depot content (including index files) is verified via OpenPGP signatures.
In short, I encourage you to further experiment with the building blocks that are already in place. In particular, if using wifi instead of bluetooth, your idea is no far off at all.
PS: İ've read some articles on your site, could I know if you already use a fuzzing system for verifying the presence of bugs in Sculpt os ? This can be an interesting topic for future articles, as soon I can I'll experiment something similar.
Is far as I know, there is no such activity. If you decide to investigate, I'd be de1igthed to hear about your findings.
Cheers Norman
-
Edoardo Mantovani -
Josef Söntgen -
Martin Stein -
Norman Feske -
ttcoder＠netcourrier.com