Re: [dev] Fwd: skvm bug and question
On 02/08/2010 06:04 PM, stateless wrote: How exactly did you execute skvm? $ skvm --help Segmentation fault I'm using the following version: (current Arch linux User Repository version) $ pacman -Qi skvm-hg Version: 0.1-1 Build Date : Sun 07 Feb 2010 01:22:21 PM CET So this should be the latest hg tip.
Re: [dev] Fwd: skvm bug and question
Hi, Could you run it through valgrind and attach the output? You can also run it under gdb and see where it fails. thx On Tue, Feb 9, 2010 at 4:49 PM, Jonas H. wrote: > On 02/08/2010 06:04 PM, stateless wrote: >> >> How exactly did you execute skvm? > > $ skvm --help > Segmentation fault > > I'm using the following version: (current Arch linux User Repository > version) > > $ pacman -Qi skvm-hg > Version : 0.1-1 > Build Date : Sun 07 Feb 2010 01:22:21 PM CET > > > So this should be the latest hg tip. > >
Re: [dev] Fwd: skvm bug and question
Hi, I have nothing to do with this issue but I just noticed something interesting: $ hg clone http://hg.suckless.org/skvm skvm requesting all changes adding changesets adding manifests adding file changes added 28 changesets with 55 changes to 13 files updating to branch default 12 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd skvm/ $ make gcc -ggdb -o skvm skvm.c -I/usr/include -I/usr/include/hal -Wall -Wextra -std=gnu99 -Wformat-security -Wshadow -Wpointer-arith -ggdb -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -lhal -lhal-storage -ldbus-glib-1 -ldbus-1 -lpthread -lrt -lgobject-2.0 -lglib-2.0 $ ./skvm --help ./skvm: unrecognized option '--help' $ make clean $ make CC=clang clang -ggdb -o skvm skvm.c -I/usr/include -I/usr/include/hal -Wall -Wextra -std=gnu99 -Wformat-security -Wshadow -Wpointer-arith -ggdb -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -lhal -lhal-storage -ldbus-glib-1 -ldbus-1 -lpthread -lrt -lgobject-2.0 -lglib-2.0 $ ./skvm --help Segmentation fault $ Hope this helps somehow.. best regards, dum8d0g On Tue, Feb 09, 2010 at 08:59:28PM +, stateless wrote: > Hi, > > Could you run it through valgrind and attach the output? You can also > run it under gdb and see where it fails. > > thx > > On Tue, Feb 9, 2010 at 4:49 PM, Jonas H. wrote: > > On 02/08/2010 06:04 PM, stateless wrote: > >> > >> How exactly did you execute skvm? > > > > $ skvm --help > > Segmentation fault > > > > I'm using the following version: (current Arch linux User Repository > > version) > > > > $ pacman -Qi skvm-hg > > Version : 0.1-1 > > Build Date : Sun 07 Feb 2010 01:22:21 PM CET > > > > > > So this should be the latest hg tip. > > > > >
Re: [dev] skvm bug and question
On 02/09/2010 09:59 PM, stateless wrote: Could you run it through valgrind and attach the output? You can also run it under gdb and see where it fails. Sure. Full-length valgrin and gdb outputs follow. Begin Valgrind/gdb output [jo...@jarchy ~]$ valgrind skvm --help ==8951== Command: skvm --help ==8951== ==8951== Invalid read of size 1 ==8951==at 0x4024B32: strncmp (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8951==by 0x422C587: _getopt_internal_r (in /lib/libc-2.11.1.so) ==8951==by 0x422D42D: _getopt_internal (in /lib/libc-2.11.1.so) ==8951==by 0x422D678: getopt_long (in /lib/libc-2.11.1.so) ==8951==by 0x804A5BB: ??? (in /usr/bin/skvm) ==8951==by 0x418FB85: (below main) (in /lib/libc-2.11.1.so) ==8951== Address 0x is not stack'd, malloc'd or (recently) free'd ==8951== ==8951== ==8951== Process terminating with default action of signal 11 (SIGSEGV) ==8951== Access not within mapped region at address 0x ==8951==at 0x4024B32: strncmp (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8951==by 0x422C587: _getopt_internal_r (in /lib/libc-2.11.1.so) ==8951==by 0x422D42D: _getopt_internal (in /lib/libc-2.11.1.so) ==8951==by 0x422D678: getopt_long (in /lib/libc-2.11.1.so) ==8951==by 0x804A5BB: ??? (in /usr/bin/skvm) ==8951==by 0x418FB85: (below main) (in /lib/libc-2.11.1.so) ==8951== If you believe this happened as a result of a stack ==8951== overflow in your program's main thread (unlikely but ==8951== possible), you can try to increase the size of the ==8951== main thread stack using the --main-stacksize= flag. ==8951== The main thread stack size used in this run was 8388608. ==8951== ==8951== HEAP SUMMARY: ==8951== in use at exit: 0 bytes in 0 blocks ==8951== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==8951== ==8951== All heap blocks were freed -- no leaks are possible ==8951== ==8951== For counts of detected and suppressed errors, rerun with: -v ==8951== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 31 from 8) Segmentation fault [jo...@jarchy ~]$ gdb skvm Reading symbols from /usr/bin/skvm...(no debugging symbols found)...done. (gdb) run --help Starting program: /usr/bin/skvm --help [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0xb7dbcf6e in strncmp () from /lib/libc.so.6 (gdb) quit End Valgrind/gdb output
[dev] Surf assumes all SSL connections are good, which is bad
I really like that Surf shows a red bar for HTTP connections and a green bar for HTTPS connections. The trouble is, Surf has no store of CA certificates, so can't be verifying server certificates. It is just assuming that any SSL connection is good. However, active network attacks are so easy to perform that saying "Well, at least Surf defends against passive easvedropping" is not really good enough. Letting people believe that any SSL connection is good is actually worse than nothing, because it creates a false sense of security. I have serious qualms about depending on CAs (the false sense of security they engender is even more of a problem, I'd argue!), but regardless, Surf needs *something*. Perhaps a straight-up SSH-style trust on first use (TOFU) mechanism? Perhaps Perspectives? Perhaps some combination?
Re: [dev] Surf assumes all SSL connections are good, which is bad
On Tue, Feb 9, 2010 at 6:09 PM, Chris Palmer wrote: > Letting people believe that any SSL connection is good is actually worse > than nothing, because it creates a false sense of security. > > I have serious qualms about depending on CAs (the false sense of security > they engender is even more of a problem, I'd argue!), stop trying to fix social problems with code SSL can do two things: 1) provide site-to-site encryption 2) make a lot of money for cert-signing organizations surf already does the first one. if you need it to do the second one, use a different browser, or else write a wrapper for surf that handles certificate verification. -- # Kurt H Maier
Re: [dev] Surf assumes all SSL connections are good, which is bad
On Tue, 9 Feb 2010 18:56:39 -0500, Kurt H Maier wrote: > On Tue, Feb 9, 2010 at 6:09 PM, Chris Palmer > wrote: >> Letting people believe that any SSL connection is good is actually worse >> than nothing, because it creates a false sense of security. >> >> I have serious qualms about depending on CAs (the false sense of security >> they engender is even more of a problem, I'd argue!), > > stop trying to fix social problems with code > > SSL can do two things: > > 1) provide site-to-site encryption > 2) make a lot of money for cert-signing organizations A man-in-the-middle attack is not a social problem. If site-to-site is not site-to-*intended*-site then your point 1) is moot. Thank you very much.
Re: [dev] Surf assumes all SSL connections are good, which is bad
On Tue, Feb 09, 2010 at 06:56:39PM -0500, Kurt H Maier wrote: > SSL can do two things: > > 1) provide site-to-site encryption Without certificate verification in some form, you have no way of knowing that. Your connection could be decrypted and re-encrypted by any number of parties along the way with no way for you to detect it. In surf's case, they don't even have to use a CN that matches the hostname. SSL without verification provides no security guarantees whatsoever.
Re: [dev] Surf assumes all SSL connections are good, which is bad
Well, the connection is definitely encrypted. Regardless of a man in the middle or not ;) However - I see your point. My suggestion would be, that we allow yet another userscript to handle this. I for one do not care for verifying certificates. But for those who do, some kind of interface would be nice, woudln't it? Surma
