dCore-5.0.alpha1 released

[SamK]

Once an SCE app is imported is it possible to apply a security upgrade (issued by Debian) to an active dCore system, or is a rebuild of the SCE app required to incorporate it?

dCore is not Debian. Nor is it traditionally "installed". dCore uses mounted squashfs as tcz and scms did. There is no rebuild, as apps are typically imported. We are only supplying scripts ( the import suite in the base of dCore ) and some server side typically setup/data scripts. You might want to think download script as used for flash.

If I understand this correctly...

If a security upgrade for an app is released into Debian Stable (of course not a feaure upgrade) it would require the app to be imported again in order for the upgrade to be included within an SCE.

If the above is correct, in a case where an app was not re-imported might it be stable but one or more of the constituent packages might have unaddressed vulnerabilities.  Does it follow that SCEs may need to be regularly re-imported in order to remain both stable and have addressed vulnerabilities?

[roberts]

Not sure of your position... But I see it as another advantage.
It is quite simple to import versus asking and waiting for a community member to recompile for relocation on current native Core, unless, perhaps, you are the type that perfers to compile everything.

Also on native Core to implement a security upgrade not only depends on a community member being available, it may also lead to breakage. 

This versus the vast community of Debian developers who maintain Debian.

But the choice is yours. We are only offering an additional Core.

If you prefer native Core you have it. It is not going away as witnessed by the on going development of Core 5. If on the other hand you had have issues with rolling release libraries and such, or your favorite package is no longer being maintained in native Core, you may want to consider dCore.

[Jason W]

I had thought of security updates, but I think most security fixes for Debian apply to server use and not standard desktop use, especially with how TC is used 99 percent of the time.  And as Robert pointed out, there are upsides and downsides to keeping with stable versions versus the latest versions of packages. 

But it was simple to code in an option in import that would provide info in the SCE to allow a check for packages that an SCE is comprised of which have been updated upstream in Debian since the SCE was imported.  A simple tool then could be ran against an SCE to inform the user which packages have been updated, and then the user can view the Debian changelog of updated packages to determine if there is need for an update based on the users particular situation.  I will consider it to be included in alpha4.

[SamK]

Not sure of your position...

The questions are not intended to be disparaging. They are motivated by a desire to understand the newly introduced SCE format.  The ability to use Core (dCore) together with apps drawn from the Debian stable repo is very appealing.

Here, TinyCore and other distros based on Debian stable are widely used.  The ability for each of them to draw apps from a common repo is a welcome simplification.



The following comments are made without having tested a dCore system yet.

Security Upgrades
The Debian stable based distros referred to above, download and install any given security upgrade only once.  This is done using a single command i.e. apt-get upgrade.  Because of their traditional installation model, this is then available system-wide.

From our previous discussion, I am guessing a dCore system might have a repeated re-import process to achieve a simalar result, i.e. once for each SCE.

From the original post announcing the SCE format a mega package can be created.

...a file list can be made of one's favorite packages and import can be used to make one mega package out of the list.  Example, a file named mydesktop that contains xfce4, leafpad, iceweasel, exaile, smplayer, etc, etc , one package per line, will make an sce of those packages that will be named mydesktop.sce.

In such a case I'm guessing that only a single re-import is required to incorporate a given security upgrade.

A dCore system might comprise multiple SCEs.  In this case I'm guessing that multiple re-imports are required to incorporate a given upgrade.  If this guess is correct might it be worth considering an OS level command to enable all SCEs within the system to be upgraded from a single command.?

...I think most security fixes for Debian apply to server use and not standard desktop use...

I'm not sure about this.  This post is being made from a general purpose desktop system running Debian 7 stable.  It has security upgrades applied regularly.

A simple tool then could be ran against an SCE to inform the user which packages have been updated, and then the user can view the Debian changelog of updated packages to determine if there is need for an update based on the users particular situation.  I will consider it to be included in alpha4.

See the suggestion above re automating the upgrade process in a single command for multiple SCEs.  While I am in favour of user choice, I also support user friendliness of operation.


Edited to improve clarity.

[Jason W]

Samk,
I am sure that there are Debian desktops all over the world that receive security updates regularly.  My point is that I am sure most of the updates are not NEEDED for desktop use.  A vulnerability in samba is not going to all of a sudden render a standard home desktop useless due to security exploits.  Even if that user runs samba to read windows shares every day on their home network.  Most dCore desktops will not have services running at all that are open to login from the outside world. 

I am not trying to trivialize security exploits, but for the typical desktop user, Linux or otherwise, by far your biggest security risk is related to behavior as in password habits and such.  And when it is all said and done, security is simply a feeling of trust and a state of mind, in life as well as Linux. 

That being said, I am testing an option in import that will let those who are security minded run a simple tool against their SCEs to list which packages contained in them have had updates since the SCE was imported, making use of the existing import structure.  And it would be simple to allow a tool to automatically re-import any SCEs that have had updates.  But I almost see it as foolish to re-import anything just because of upstream updates that have occurred when I don't even know if they apply to my situation.   I am not focusing much time on this, the option to generate the needed info took less than an hour to make and test.  But I knew the question of updates would come up.  And an option to re-import everything will not be in it's initial conception, I don't want to promote that as a needed behavior.

What may materialize in the near future is a simple tool that will list each component of an SCE that has been updated in Debian, and then the user can review the below page to see if there is a vulnerability found that may apply to a package that they feel warrants keeping a close eye on updates, for instance if they were running an SSH server of critical importance.

http://www.debian.org/security/2013/

But to be honest I would rather attention be placed on finding bugs in imported packages or the dCore import tools.  In this early stage, things may change quick enough that would require re-importing SCEs long before security concerns are justifiable.

[SamK]

• Jason W[/b]
  Thanks for your detailed response.
  
  
  

  My point is that I am sure most of the updates are not NEEDED for desktop use. 
  
  ...for the typical desktop user, Linux or otherwise, by far your biggest security risk is related to behavior as in password habits and such.

  A reasonable assessment.  Whether or not the security upgrades are needed is not always apparent to a user with limited knowledge.  In such a case the safer option is to install them.
  
  
  

  ...an option to re-import everything will not be in it's initial conception, I don't want to promote that as a needed behavior.

  The idea was offered as I have an unmeasured feeling that many users of Debian stable simply accept all security upgrades as a matter of course via apt or synaptic.  As the upgrades come from the stable repository this can be done without adversely affecting the system, which is not the case if using a non-stable Debian repo.  As its is safe, although possibly uneeded behaviour on the part of the user, it would make dCore friendlier and familiar to them.
  
  
  

  ...the user can review the below page to see if there is a vulnerability found that may apply to a package that they feel warrants keeping a close eye on updates...

  That assumes the user has sufficient expertise to interpret the information and the ramifications it has on the local system.  While this may be fine for experts and enthusiasts, it may be less suitable for users who want to use their system rather than having to learn about the finer point of system management.  After all that may be one of the reasons they were drawn towards the stable repo in the first place.
  
  
  

  ...I would rather attention be placed on finding bugs in imported packages or the dCore import tools.

  Perfectly understandable.  You are of course in the ideal position to judge where the time and effort is best directed to  get dCore up and running.

[vinnie]

There is a command to browse, find and install from the debian repository list, or you have to search from the site http://www.debian.org/distrib/packages ?

ok, I see the menu when I'm importing the file 

[theYinYeti]

Hi Jason W!
I just gave alpha3 a shot. It’s plain that it’s a work in progress. And yet, I was very impressed with the result!
From memory and a bit of script-exploring, I managed to type the commands to install elinks (import -b elinks; loadsce elinks). From there, I was able to find this topic and follow the directions of the first post: Xprogs+Xtc, then Xsetup.sh.
The only real difficulty I encountered was that X refused to start. That was due to Xorg not having the “s” bit set. I went into savage mode In /usr/bin, I removed everything linking to /tmp/tcloop/xorg-all, then copied the files over, and ran “sudo chmod +s *” Then X started (startx).
I found myself on an all-black desktop, found out that there was a mouse-click menu, from which I could open a terminal (Xterm), and thus launch wbar. I did not try everything, but I saw that the import icon failed to do anything (apart from a quick flicker of a terminal window, I think).

All in all, I tried only 2 imports: elinks, and xorg-all (using Xsetup.sh). I was at first a bit worried by all the many warnings, mostly about permission denied to create links. But in the end, elinks worked right from the first attempt! And Xorg too… mostly And XOrg is quite a beast!
Very good job Jason W! Keep up like that!

I won’t be using dcore before probably at least a year: I wouldn’t know where to replicate all the nice customizations I did to my TinyCore (see signature). But I sure will keep an eye on the project

[edit: for your information, my sce directory with Xprogs, Xtc, elinks, and xorg-all, was about 115 MB in size]

[Jason W]

You need a window manager installed.  Some are fluxbox, openbox, icewm, flwm.  Or xfce4 and lxde are available as larger desktops, I have even run gnome and kde on dCore. 

The error messages you see are from startup scripts.  They are almost purely cosmetic and in time they will be cleaned up more.

I have never seen the Xorg issue on any of my machines, but I will look into a "chmod +s" option to avoid this for others.

EDIT:  "chmod +s" command added to startup script of xorg

[roberts]

If one runs Xsetup.sh, then flwm-topside.sce is downloaded and added to sceboot.lst. However, no matter which window manager one chooses, via import or prebuilt sce, you will need to specify it via the desktop bootcode, e.g., desktop=flwm_topside

[Jason W]

Thanks Robert for pointing that out, I forgot that flwm_topside was loaded as part of Xsetup.sh.  Maybe as part of each window manager or desktop environment package the startup script could contain " [ -s /etc/sysconfig/desktop ] || echo fluxbox > /etc/sysconfig/desktop " substituting fluxbox for whatever appropriate name.   That way if the preferred DE or WM package is specified at boot, that would hold regardless of what is later imported and installed.  And if no DE or WM is specified at boot, importing and loading one would just work but none would overwrite an existing /etc/sysconfig/desktop entry that is either set at boot or with a previously loaded WM/DE package. 

[gerald_clark]

I can't find anything that sets /etc/sysconfig/Xserver, so how do you get X to start at login?
I stuck something in bootlocal.sh to create it, but that doesn't seem right.

[roberts]

It will be fixed in next cut. As there is no Xvesa in dCore, .profile can be adjusted as follows.

[ ! -f /etc/sysconfig/Xserver ]

with

[ ! -f /usr/local/tce.installed/xorg ]

This will allow X to start upon login.
This change can be effected now in your .profile and backup will restore it.

Without the change just typing startx at the prompt works as expected

[roberts]

RE: desktop specification...
I left it to be user specified by boot code to be consistent. Otherwise every possible WM/DE that could be imported would have to have a local server startup script be created and merged during import's sce creation. Of course, it can be done. The question is the effort worth the result?

[vinnie]

First, I tried dcore through virtualbox on fat32 flash stick with creation of a vmdk disk image (VBoxManage internalcommands createrawvmdk -filename ./gialla.vmdk -rawdisk /dev/sdc1).
I did start the distro through an iso (mounted as cd) and installed the packages in the tce directory inside the pen usb.
After I tried to run it directly on the pc.

Ok, after some testing:

1) I saw that during the import of packets in an error like this, also these are purely cosmetic?:

Code: [Select]

...
Connecting to ftp.us.debian.org (64.50.233.100:00)
libcairo2_1.12.2-3_1 100% |*******************************|   921k 0:00:00 ETA
Merging libcairo2: cpio: can't create symlink from usr/lib/i386-linux-gnu/libcairo.so.2 to libcairo.so.2.11200.2: Operation not permitted
2146 blocks
...
2)I am currently using unetbootin, is there any automated way to install dcore on flash memory or what procedure should I follow?

3)imported wbar seems not to work

4)imported firefox return this error:

Code: [Select]

tc@box:~$ firefox
XPCOMGlueLoad error for file /tmp/tcloop/firefox/usr/lib/firefox/libxul.so:
libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
5)Uxterm in flwm menu return this error:

Code: [Select]

UXterm da questo errore (xmessage)
uxterm tried unsuccessfully to use locale en_US.UTF-8 by setting $LANG to "en_US.UTF-8"
6) the wm clfswm seems not work

7) how I use wifi, I can not find the script wifi.sh, I have installed this packages:
firmware-atheros
wl-modules-3.8.10-tinycore
wireless-3.8.10-tinycore
wireless-tools