Core v6.2rc2

[Juanito]

does this still happen if your firefox extension is not loaded?

As mentioned elsewhere the vlc recompile is in the maintainers task queue.

[coreplayer2]

Since previously mentioned re wbar disappearing,  after a full system update (dep's and extensions) I no longer experience this anomaly

I think it's safe to assume it is caused by outdated extensions



Sent from my iPhone using Tapatalk

[nitram]

- Apps > Maintenance > Md5 Checking: Many users probably check their entire install, not just select extensions. Would be great if there was a select all checkbox and any problematic md5 checks were flagged in red or yellow text, rather than scrolling a long list of black and white OKs.

- Dependencies > Update .dep files: Painfully slow to update. Takes ~10 minutes to complete while Apps window blanks with hourglass cursor. Shouldn't this be completed within a few seconds or a minute? Conky shows <10% CPU usage (800MHz system), some network activity, good wired DSL connection, not performing any background tasks and system otherwise runs great. Optional folder has 409 files/120MB and OnDemand list 10 items. Apps window usually redraws itself when completed, otherwise Alt-Tab between applications redraws Apps window contents.

Quick follow-up. All items noted in my earlier post remain with the exception of the following. Hope someone can address them either way - any feedback is appreciated.

Regarding the two items quoted above:

- Just noticed the subtle yellowish line and FAILED flag on a failed md5 - that's great thanks. Maybe just too subtle for my ageing eyes or maybe because i'm using Xvesa.

- Dependencies > Update .dep files ran quick for me today. Tested twice and only took ~45 seconds each trial. Not sure why so slow when i reported the issue earlier. If nobody else experiences this slowness then maybe just my system. My hardware is old, limited and had just finished compiling with numerous extensions loaded. Since the initial slowness issue, i've also removed several extensions (primarily Xorg related) but the optional folder is still 371 files, 120 MB.

New item, is this a security concern? Apps > md5 Checking loads all .tcz.md5.txt files but doesn't check to ensure all extensions have an associated md5.txt file. These extensions, therefore, never get flagged or md5 checked. This obviously occurs when extensions i've compiled are copied into optional without an md5.txt file. So in theory if someone gets into a system, swaps in a compromised .tcz extension and removes the md5.txt file, no one would be the wiser. Shouldn't Apps check, flag and report missing md5.txt files?

[Juanito]

New item, is this a security concern? Apps > md5 Checking loads all .tcz.md5.txt files but doesn't check to ensure all extensions have an associated md5.txt file. These extensions, therefore, never get flagged or md5 checked.

For me this is a good way to avoid having personal extensions continually flagged - if they don't have an md5sum, then they are ignored.

[nitram]

Thanks for the response. Your point is understood but to me this issue is an oversight. Just wanted to report a potential exploit. If i knew how to program i would attempt a patch, reporting any optional folder .tcz extensions not associated with an md5.txt file, but i can't so up to you/developers whether it's worthy of addressing.

Given the choice, i typically prefer security over convenience. Probably not a big concern for the average home user, but maybe for kiosk operators, etc. Flagging missing md5.txt files wouldn't need to compromise the functionality of the .tcz extension, just ensure the end user is notified of a potential issue.

[gerald_clark]

One can always add a check of the md5sum files to bootsync.sh.
However, once access is obtained, there is no security.

[bmarkus]

Thanks for the response. Your point is understood but to me this issue is an oversight. Just wanted to report a potential exploit. If i knew how to program i would attempt a patch, reporting any optional folder .tcz extensions not associated with an md5.txt file, but i can't so up to you/developers whether it's worthy of addressing.

I do not see why and how a missing md5 is imposing a security risk.

[gerald_clark]

Core is a toolkit, not a distro.
You can add a simple script to md5sum the whole optional directory at boot.
If you can't, why are you using core instead of a distro targeted for the end user?

[beerstein]

Tested install again. When I installed leafpad the wbar also disappeared. Then I brought back the wbar using the control panel and tcWbarConf --Apply.
Then installed Firefox and wbar was gone again. After installing several more extensions all of the sudden the wbar did not disappear after an install. Strange?
BTW: I was using CorePlus in cloud mode.

[coreplayer2]

Given the choice, i typically prefer security over convenience. Probably not a big concern for the average home user, but maybe for kiosk operators, etc. Flagging missing md5.txt files wouldn't need to compromise the functionality of the .tcz extension, just ensure the end user is notified of a potential issue.

This is deliberate. At a minimum it's a means to prevent auto-update and accidental removal of modded or personal extensions.   I do have a solution and have been using it for a year or more, just need to submit it  (wasn't sure if anyone would be interested..).

[nitram]

Thanks for the reponses.

gerald_clark wrote:
One can always add a check of the md5sum files to bootsync.sh.
However, once access is obtained, there is no security.

An occasional manual md5sum check via Apps is good enough for me, but as outlined the check is only valid if the .tcz extension has an associated md5.txt file. So in that sense it is really only a partial and incomplete check. Why run a checker if it only performs a partial job. Of course once access is obtained security is compromised, but providing awareness of missing md5.txt files could help detect possible intrusion/corruption.

bmarkus wrote:
I do not see why and how a missing md5 is imposing a security risk.

Well to me the purpose of an md5 check is not only to confirm an accurate download, but also to help ensure there is no curruption in the system post-install, which could be secondary to a security violation. Does that not make sense?

gerald_clark wrote:
Core is a toolkit, not a distro.
You can add a simple script to md5sum the whole optional directory at boot.
If you can't, why are you using core instead of a distro targeted for the end user?

BusyBox is a toolkit, TinyCore is a distribution.

If not, maybe someone should notify distrowatch and update the TinyCore website:

About Our Project
Our goal is the creation of a nomadic ultra small graphical desktop operating system capable of booting from cdrom, pendrive, or frugally from a hard drive.

http://distro.ibiblio.org/tinycorelinux/

As already outlined, a simple script to md5sum check the optional directory at boot is futile if .tcz extensions in the optional folder are missing an associated md5.txt file. They don't get flagged or checked.

coreplayer2 wrote:
This is deliberate. At a minimum it's a means to prevent auto-update and accidental removal of modded or personal extensions.   I do have a solution and have been using it for a year or more, just need to submit it  (wasn't sure if anyone would be interested..).

Sorry i don't buy that, Apps > md5 Checking is not designed to update or remove any extensions, modded or personal, it's simply an automated way to complete an md5 check - no system changes. And in it's present state the md5 check is incomplete. Although i appear to be a minority, i would definitely be interested in your solution.

Still can't understand the resistance to flagging missing md5.txt files. How could incorporating this feature be a bad thing? Why should a user need to manually scroll through an optional folder to check for missing md5.txt files when a computer can check so much quicker and reliably.

[gerald_clark]

Core Concepts
On behalf of the Tiny Core Team, welcome. Please take the time to read this document and understand the philosophies behind Tiny Core.

One quick user beware: Tiny Core is not a turn-key operating system. At least initially, almost all users will require internet access to the online repository.


--------------

Downloaded programs WILL have an md5 file.
There is nothing preventing you from keeping your own md5sum file of all the tcz files in the optional directory.
Then a simple md5sum -c command will verify all packages at boot.

Core is NOT a secure system.  All security must be added by the user.
Once an outsider gains access, no program can be trusted.  All the features you think would add security could be faked.

The installation from scratch concept of loading everything anew on each boot does allow you the ability to check the authenticity of your extensions,
but only if you keep the sums on separate storage.  If you suspect an intrusion occurred, you would need to boot from a secured thumbdrive and verify the checksums on your persistent storage. Once verified, you could then do your normal boot.

[Juanito]

Tested install again. When I installed leafpad the wbar also disappeared. Then I brought back the wbar using the control panel and tcWbarConf --Apply.
Then installed Firefox and wbar was gone again. After installing several more extensions all of the sudden the wbar did not disappear after an install. Strange?
BTW: I was using CorePlus in cloud mode.

I just downloaded CorePlus-6.2rc2.iso, burnt it to CD and booted from the CD using flwm classic.

Downloading and loading firefox and leafpad did not make wbar disappear for me...

[Juanito]

The tinycorepure64 legacy-bios/(u)efi multiboot iso has been further slimmed down and is available here:

http://tinycorelinux.net/6.x/x86_64/release_candidates/TinyCorePure64_mb-6.2rc2.iso

The iso is now "only" 3.2mb bigger than the standard version (including 2.4mb of efi fonts).

Most, if not all, (u)efi boot machines appear to be able boot legacy-bios cd/dvd, but there may be advantages to using (u)efi boot:

* drivers may boot up in a faster mode (this was the case with the hd controller in my last laptop)
* there are less non-critical errors reported on boot (manufacturers giving priority to (u)efi boot)
* displays over 1024x768 work at native resolution with Xfbdev

..and this is an easy way to check if your machine will (u)efi boot...

Note that on my hardware with a usb cd/drive and uefi boot, it takes +/- 12s for anything to happen after selecting the tcw (tc waitusb) menu entry.

[nitram]

Tested install again. When I installed leafpad the wbar also disappeared. Then I brought back the wbar using the control panel and tcWbarConf --Apply.
Then installed Firefox and wbar was gone again. After installing several more extensions all of the sudden the wbar did not disappear after an install. Strange?

I've had similar experiences with wbar using Firefox, could have been other applications too, using TC6.0 at the time. As i find wbar buggy, on my recent TC installs i now promptly remove wbar and switch to JWM. Since TC aims to provide lean releases, query why it is provided by default in TinyCore, as clicking the FLTK desktop provides all necessary functionality to get started.