Page 36 of 44

Posted: Mon 24 Dec 2012, 07:32
by goingnuts
bark_bark_bark wrote:I fixed the Tinycore and converted it to sfs3 format for pupngo to use.
Good! Looking forward to test (if you plan to release it.)

Posted: Mon 24 Dec 2012, 11:08
by bark_bark_bark
1 problem, I have to start over. Why? I damaged the win partition that had the custom pupngo iso image with the new tc. Also the Xserver never fully loaded when doing xwin. Still needs work.

Posted: Fri 04 Jan 2013, 22:33
by goingnuts
As there are pupngo all over the place anyway I take the opportunity to post an update of the tiny Xvesa source. Now it can be build with 13 extensions (DEC-XTRAP, DPMS, MIT-SCREEN-SAVER, MIT-SHM, RANDR, RECORD, RENDER, SHAPE, SYNC, TOG-CUP, XC-MISC, XTEST and XVideo) but that seems also to be more or less what this source can deliver without some severe code-additions (well - source for XINPUT & XKB is still partly present but question is if its worth fixing).
Without extensions Xvesa builds to 543K and with all the extensions it sums up to 728K static with uclibc & tinyX11 (Xfbdev being approx. 16K smaller).
As some additional code has been added I moved the version to 0.02 :)
20130513: Removed attachment as forum does not support the size anymore

Posted: Fri 04 Jan 2013, 22:55
by starhawk
I don't see that source, or a link to it ;)

Just sayin'...

EDIT: nevermind, I see it now.

pUPnGO

Posted: Sat 05 Jan 2013, 11:52
by Jan99
Hello,

I have installed pUPnGo _v412_160612 frugal to my harddisk.
As far as I have tested it runs well expect for the cryptoloop aes & blowfish.

I usualy use an heavy encrypted save file (aes) puppysave file.
The option to create one at shutdown is there but the created file can not be mounted (both heavy & light encryption).

From terminal I see the following:
# mount -o encryption=aes test ~/cmnt
Unsupported encryption type aes
# mount -o encryption=blowfish test ~/cmnt
Unsupported encryption type blowfish
# mount -o encryption=xor test ~/cmnt
Password:

Can someone please correct this bug?

Posted: Sun 06 Jan 2013, 10:54
by goingnuts
Jan99: Thanks for reporting this severe bug! It should be fixed now.

Posted: Sun 06 Jan 2013, 16:33
by starhawk
@Jan99: FYI, see here --> http://murga-linux.com/puppy/viewtopic. ... 823#675823

Hope that's helpful ;)

pUPnGO

Posted: Sun 06 Jan 2013, 18:55
by Jan99
@starhawk,

I had already seen that Thanks anyway.

There should be my bug report in the first place sorry for posting it here.

Yes now encrypted save file is working perfectly.

Posted: Sat 02 Feb 2013, 19:50
by goingnuts
I have been messing with XFree86 4.8.0 and created a static build of XFree86 which holds a lot of drivers for various graphic cards. Attached a build with mesa and glx. The install is a bit tricky as not much in pupngo/puppy is targeted XFree86:
Install the package
Delete your present X symlink (rm -f /usr/X11R7/bin/X)
Symlink XFree86 to X (cd /usr/X11R7/bin; ln -s Xfree86 X)
Now exit to prompt
run 'XFree86 -configure'
Copy the generated /root/XF86Config.new to /etc/X11 (cp /root/XF86Config.new /etc/X11)
start X with xinit

You should now be running XFree86.
It quite big (>3MB upx-ed, > 8Mb uncompressed) but delivers the following extensions:
BIG-REQUESTS
DEC-XTRAP
DPMS
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RANDR
RECORD
RENDER
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XC-MISC
XFree86-Bigfont
XFree86-DGA
XFree86-Misc
XFree86-VidModeExtension
XInputExtension
XKEYBOARD
XTEST
XVideo
I do not know much about the configuring of XFree86 - but changing things in /etc/X11/XF86Config is the way to go.
I got my mouse scroll working with:
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "imps/2"
Option "Device" "/dev/mouse"
Option "ZAxisMapping" "4 5"
EndSection
ohh - and the download link :)

Posted: Sat 02 Feb 2013, 20:49
by technosaurus
I previously mentioned mupdf's thirdparty archive has minimal (read-only) configurations of freetype, jpeg, openjpeg, zlib and jbig2 (the config files are in mupdf's scripts directory)

I just wanted to add that libpng similarly has a lot of user configurable parameters but no preexisting build actually builds the library, but inside the contrib subdirectory, they do have a shortcut to making a read-only png library (useful for everything except image editors)

I can put these together to use in the libtiny package (probably could drop the X11) if others are interested... probably shift to musl as well as the 0.9.9 release seems to build quite nicely

does anyone have input on a C++ library? uclibc++ seems to work ok with musl, but the ustl project looks promising

btw, I started working on this in light of jwm's recent support for svg images via librsvg, but am trying to port it to use libsvg or libtinysvg instead to avoid the cairo dependency (I decided on libsvg because libtinysvg doesn't support embedded png/jpeg images AFAIK)

Posted: Sun 03 Feb 2013, 07:22
by Ibidem
technosaurus wrote:I previously mentioned mupdf's thirdparty archive has minimal (read-only) configurations of freetype, jpeg, openjpeg, zlib and jbig2 (the config files are in mupdf's scripts directory)

I just wanted to add that libpng similarly has a lot of user configurable parameters but no preexisting build actually builds the library, but inside the contrib subdirectory, they do have a shortcut to making a read-only png library (useful for everything except image editors)

I can put these together to use in the libtiny package (probably could drop the X11) if others are interested... probably shift to musl as well as the 0.9.9 release seems to build quite nicely

does anyone have input on a C++ library? uclibc++ seems to work ok with musl, but the ustl project looks promising

btw, I started working on this in light of jwm's recent support for svg images via librsvg, but am trying to port it to use libsvg or libtinysvg instead to avoid the cairo dependency (I decided on libsvg because libtinysvg doesn't support embedded png/jpeg images AFAIK)
There is a libpnglite, somewhere...no idea what the difference is.

ustl needs source changes: it uses <ustl.h> and namespace ustl.

Posted: Tue 05 Feb 2013, 15:27
by Ibidem

Code: Select all

$ ls -l Xfbdev Xvesa 
-rwxr-xr-x 1 idunham idunham 557972 Feb  4 22:39 Xfbdev
-rwxr-xr-x 1 idunham idunham 574264 Feb  4 22:39 Xvesa
Linked with my patched version of musl statically (I had to change __{u,g}id_t to {u,g}id_t and {IF,IOPL}_MASK to X86_EFLAGS_{IF,IOPL} for Xvesa to work.)

Now for the fun part:
It errors complaining about bieng unable to find default font "fixed" and not being able to open /usr/X11R7/lib/X11/fonts/misc
I'm running Debian Squeeze, so this is well away from the real location. What does

Code: Select all

find /usr/X11R7/lib/X11/fonts/ 
show on a pupngo system with working tinyx?

Posted: Tue 05 Feb 2013, 15:35
by goingnuts
Just tested in pupngo2012 and it says:
/usr/X11R7/lib/X11/fonts
/usr/X11R7/lib/X11/fonts/100dpi
/usr/X11R7/lib/X11/fonts/75dpi
/usr/X11R7/lib/X11/fonts/CID
/usr/X11R7/lib/X11/fonts/Speedo
/usr/X11R7/lib/X11/fonts/TTF
/usr/X11R7/lib/X11/fonts/Type1
/usr/X11R7/lib/X11/fonts/misc

Posted: Tue 05 Feb 2013, 19:40
by Ibidem
goingnuts wrote:Just tested in pupngo2012 and it says:
/usr/X11R7/lib/X11/fonts
/usr/X11R7/lib/X11/fonts/100dpi
/usr/X11R7/lib/X11/fonts/75dpi
/usr/X11R7/lib/X11/fonts/CID
/usr/X11R7/lib/X11/fonts/Speedo
/usr/X11R7/lib/X11/fonts/TTF
/usr/X11R7/lib/X11/fonts/Type1
/usr/X11R7/lib/X11/fonts/misc
OK, thanks.
Solution was to change -DCOMPILEDFONTDIR to /usr/share/fonts/X11...and fonts worked.
OTOH, my system's terminal didn't get keyboard input, probably due to xkb.

I've made a couple more changes to os/utils.c, backporting security fixes. Several other security fixes are needed, though; I plan to post my sources as soon as I have them added.
-if you define USE_CHMOD, it allows an attacker to change the permissions of any file on the system
-and there's another bug that's harder to explain

Code: Select all

commit 3b3cf4a05aabf56aeca7edb65c2a3455fd65c265
Author: Isaac Dunham <idunham@lavabit.com>
Date:   Tue Feb 5 10:00:27 2013 -0800

    Fix CVE-2011-4028, CVE-2011-4029.
    
    Based on patches by Matthieu Herrb.
    Avoid revealing whether file exists (|O_NOFOLLOW)
    and avoid race that allows setting any file to mode 0444
    (delete USE_CHMOD, which was vulnerable).

diff --git a/os/utils.c b/os/utils.c
index ef42a24..147ce01 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -294,11 +294,10 @@ LockServer()
   (void) sprintf(pid_str, "%10ld\n", (long)getpid());
   (void) write(lfd, pid_str, 11);
 #ifndef __EMX__
-#ifndef USE_CHMOD
+  /* 
+   * Don't use chmod, ever. CVE-2011-4029: file permission change vulnerability
+   */
   (void) fchmod(lfd, 0444);
-#else
-  (void) chmod(tmp, 0444);
-#endif
 #endif
   (void) close(lfd);
 
@@ -319,8 +318,9 @@ LockServer()
     else {
       /*
        * Read the pid from the existing file
+       * Don't follow symlinks, CVE-2011-4028
        */
-      lfd = open(LockFile, O_RDONLY);
+      lfd = open(LockFile, O_RDONLY|O_NOFOLLOW);
       if (lfd < 0) {
         unlink(tmp);
         FatalError("Can't read lock file %s\n", LockFile);

Posted: Tue 05 Feb 2013, 20:08
by goingnuts
Cool! Any chance that one could "backport" the composite? Would be nice if we could get more of the extensions added (as a choice) and working...

Posted: Wed 06 Feb 2013, 01:26
by Ibidem
goingnuts wrote:Cool! Any chance that one could "backport" the composite? Would be nice if we could get more of the extensions added (as a choice) and working...
http://cgit.freedesktop.org/xorg/xserve ... 553c7d3342
That's the commit that added it.
Judging by age, it should be practical...but, it's 4000+ lines.
Once you get too much "backporting" done, you end up with pretty much the same thing as the newer code, and lose the size advantage of the older code. The security fixes alone will probably cost a few kb. I have about four more to go.

And FYI:
Upstream Xorg hasn't supported TOG-CUP since 2008.

UPDATE:
It turns out only about 6 of ~10 CVEs affected tiny-Xserver.
The rest were in code that was not present. ;)

Posted: Wed 06 Feb 2013, 05:19
by Ibidem
OK, I've gotten the CVE backports done.
You'll probably want to keep standard_definitions.mk from 0.02, since I've adjusted it for a musl build on Debian.
Also, adding -DHAVE_STDINT_H=1 will allow including stdint.h...but MAX_UINT32 is defined manually otherwise.

Hmmm. Attachment is too big. Max Size: 256 kb.
I can squeeze the tarball down to 870kb, but no further (that's xz -9c).

So I'm uploading a diff and no more.


I'll see about putting this on github too.

Posted: Wed 06 Feb 2013, 07:00
by Ibidem
Here's the missing functions for xkb:

Code: Select all

noXkbExtension
ProcessKeyboardEvent
ProcessPointerEvent
XkbApplyMappingChange
XkbDisableComputedAutoRepeats
XkbExtensionInit
XkbFilterEvents
XkbFinishDeviceInit
XkbFreeInfo
XkbFreeSrvLedInfo
XkbHandleBell
XkbInitDevice
XkbProcessArguments
XkbRemoveResourceClient
XkbSetIndicators
XkbSetRepeatKeys
XkbUseMsg

Posted: Wed 06 Feb 2013, 16:37
by goingnuts
Ibidem: Thanks a lot for looking at this! I could not get the patch to /hw/kdrive/vesa/vm86.c to build - otherwise it seems ok. I also have FontCache extension to show up (xdpyinfo) but does not work correct (needed for abiword).
Did initial trial to implement the composite but failed so have been looking for a release of Xorg/Xfree with composite and where Kdrive is present but found none. Anyone know where to look?

Posted: Wed 06 Feb 2013, 18:04
by Ibidem
goingnuts wrote:Ibidem: Thanks a lot for looking at this! I could not get the patch to /hw/kdrive/vesa/vm86.c to build - otherwise it seems ok. I also have FontCache extension to show up (xdpyinfo) but does not work correct (needed for abiword).
Did initial trial to implement the composite but failed so have been looking for a release of Xorg/Xfree with composite and where Kdrive is present but found none. Anyone know where to look?
1: Which libc? uClibc or musl?
I should note that in the latter case, it requires a patched version (my g_hack branch from github.com/idunham/musl )
In the former case, I'm guessing it's a kernel-specific issue. Current uClibc includes <asm/vm86.h>, which includes <asm/processor-flags.h>, which currently defines X86_EFLAGS_* rather than *_MASK.
I could use

Code: Select all

#ifndef IF_MASK
#ifdef X86_EFLAGS_IF
#define IF_MASK X86_EFLAGS_IF
#define IOPL_MASK X86_EFLAGS_IOPL
#endif
#endif
2. I'm under the impression it should be Xorg 6.8.? or later (possibly, there's some sort of patch for that version), or xorg-xserver 1.4 to 1.6.x

However, there's pretty few programs that need composite, afaict.