Discussion:
please compile official fossil builds with https support
(too old to reply)
Eric Rubin-Smith
2015-06-10 19:25:06 UTC
Permalink
$ fossil pull
Pull from https://eas@<...>/
HTTPS: Fossil has been compiled without SSL support
Pull done, sent: 0 received: 0 ip:
$

This burdens adoption, since now I have to build my own fossil and
distribute that to people on my team internally, rather than just pointing
them at the web site.

If you are worried that some people don't want the bloat of openssl in
their base fossil, perhaps provide both options on the site?
Richard Hipp
2015-06-10 19:30:25 UTC
Permalink
Post by Eric Rubin-Smith
If you are worried that some people don't want the bloat of openssl in
their base fossil, perhaps provide both options on the site?
It's not a question of bloat, its a question of whether or not we
require the user to have previously done "apt-get install openssl
libssl" (or whatever other magic incantation is required to get the
right shared libraries running).
--
D. Richard Hipp
***@sqlite.org
Eric Rubin-Smith
2015-06-10 19:37:22 UTC
Permalink
Post by Richard Hipp
Post by Eric Rubin-Smith
If you are worried that some people don't want the bloat of openssl in
their base fossil, perhaps provide both options on the site?
It's not a question of bloat, its a question of whether or not we
require the user to have previously done "apt-get install openssl
libssl" (or whatever other magic incantation is required to get the
right shared libraries running).
I guess I had assumed you could bake it in statically. Is that a
non-option for yall?

Eric
Richard Hipp
2015-06-10 19:46:20 UTC
Permalink
Post by Eric Rubin-Smith
Post by Richard Hipp
Post by Eric Rubin-Smith
If you are worried that some people don't want the bloat of openssl in
their base fossil, perhaps provide both options on the site?
It's not a question of bloat, its a question of whether or not we
require the user to have previously done "apt-get install openssl
libssl" (or whatever other magic incantation is required to get the
right shared libraries running).
I guess I had assumed you could bake it in statically. Is that a
non-option for yall?
Can you send me the apt-get command for installing the necessary
static libraries?

This came up before. Seems like somebody said that there are issues
with openssl that prevent it from being statically linked. But I
don't recall the details.
--
D. Richard Hipp
***@sqlite.org
Eric Rubin-Smith
2015-06-10 20:03:37 UTC
Permalink
Post by Richard Hipp
Post by Eric Rubin-Smith
Post by Richard Hipp
Post by Eric Rubin-Smith
If you are worried that some people don't want the bloat of openssl in
their base fossil, perhaps provide both options on the site?
It's not a question of bloat, its a question of whether or not we
require the user to have previously done "apt-get install openssl
libssl" (or whatever other magic incantation is required to get the
right shared libraries running).
I guess I had assumed you could bake it in statically. Is that a
non-option for yall?
Can you send me the apt-get command for installing the necessary
static libraries?
I believe you should be able to say:

# apt-get install libssl-dev

yielding /usr/lib/x86_64-linux-gnu/libssl.a and libcrypto.a on my arch.

This came up before. Seems like somebody said that there are issues
Post by Richard Hipp
with openssl that prevent it from being statically linked. But I
don't recall the details.
I've been building my own openssl and statically linking it into programs
running on little things like home routers for around a year now. I assume
you don't want to fiddle with building your own openssl, but I'm happy to
share my makefile magic if so.

I also don't know whether a static build has any legal/licensing
implications on fossil that you'd find undesirable.

Eric
Richard Hipp
2015-06-10 20:42:41 UTC
Permalink
Post by Eric Rubin-Smith
# apt-get install libssl-dev
That seemed to work. Thanks. I can now do the build with
"./configure --static --disable-lineedit". (The --disable-lineedit
was necessary because apparently only the GNU readline package insists
on being dynamically linked.)

The new build is now on the website.
--
D. Richard Hipp
***@sqlite.org
Richard Hipp
2015-06-10 20:48:12 UTC
Permalink
Post by Richard Hipp
Post by Eric Rubin-Smith
# apt-get install libssl-dev
That seemed to work. Thanks. I can now do the build with
"./configure --static --disable-lineedit". (The --disable-lineedit
was necessary because apparently only the GNU readline package insists
on being dynamically linked.)
The new build is now on the website.
Oh, wait. That won't work!

We have to publish an x86 build for the people still on older
hardware. And there is not an openssl available that works with -m32,
at last that I know of.

Eric: Can you discover what apt-get is needed in order to statically
link libssl using -m32?
--
D. Richard Hipp
***@sqlite.org
Eric Rubin-Smith
2015-06-11 00:50:30 UTC
Permalink
Post by Richard Hipp
Eric: Can you discover what apt-get is needed in order to statically
link libssl using -m32?
Perhaps this?

# apt-get install libssl-dev:i386

Warning: I just got that command line from google and verified apt-get
accepted it -- didn't actually try to link against the libs in that package.

Eric
Eric Rubin-Smith
2015-06-11 01:56:19 UTC
Permalink
Post by Richard Hipp
Eric: Can you discover what apt-get is needed in order to statically
Post by Richard Hipp
link libssl using -m32?
Perhaps this?
# apt-get install libssl-dev:i386
Warning: I just got that command line from google and verified apt-get
accepted it -- didn't actually try to link against the libs in that package.
I poked at this some more and it seems to work:

[little:fossil-src-1.33] $ make distclean
rm -rf bld/* fossil
rm -f autoconfig.h config.log Makefile
[little:fossil-src-1.33] $ export CFLAGS=-m32 LDFLAGS=-m32
[little:fossil-src-1.33] $ ./configure --with-openssl
Host System...x86_64-unknown-linux-gnu
Build System...x86_64-unknown-linux-gnu
C compiler... cc -m32
C++ compiler... c++ -m32
Build C compiler...cc
Checking for stdlib.h...ok
Checking for uint32_t...ok
Checking for uint16_t...ok
Checking for int16_t...ok
Checking for uint8_t...ok
Checking for pread...ok
Checking for tclsh...ok
Checking for ssl in 1...ok
HTTPS support enabled
Checking for zlib.h...ok
Checking libs for inflateEnd...-lz
Checking for readline/readline.h...not found
Checking for editline/readline.h...not found
Checking libs for gethostbyname...none needed
Checking libs for socket...none needed
Checking libs for iconv...none needed
Checking for utime...ok
Checking for usleep...ok
Checking for strchrnul...ok
Checking for getloadavg...ok
Checking for getpassphrase...not found
Checking libs for getpass...none needed
Checking libs for dlopen...-ldl
Checking libs for sin...-lm
Checking libs for fuse_mount...no
Created Makefile from Makefile.in
Created autoconfig.h
[little:fossil-src-1.33] $ vi Makefile
... make this edit:
--- Makefile.old 2015-06-10 21:53:54.376496452 -0400
+++ Makefile 2015-06-10 21:54:02.664496097 -0400
@@ -38,7 +38,7 @@
#
TCLSH = tclsh

-LIB = -m32 -L1/lib -lssl -lcrypto -lz -ldl -lm
+LIB = -m32 -L1/lib /usr/lib/i386-linux-gnu/libssl.a
/usr/lib/i386-linux-gnu/libcrypto.a -lz -ldl -lm
TCCFLAGS = -I1/include -m32 -DHAVE_AUTOCONFIG_H
-D_HAVE_SQLITE_CONFIG_H
INSTALLDIR = $(DESTDIR)/usr/local/bin
USE_SYSTEM_SQLITE = 0

[little:fossil-src-1.33] $ make -j10
...
[little:fossil-src-1.33] $ file ./fossil
./fossil: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=6ed3d241209ed598c1ac326e169ff40239ad5f5f, not stripped
[little:fossil-src-1.33] $ ldd ./fossil
linux-gate.so.1 => (0xf76f9000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf76bd000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76b8000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7671000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74c3000)
/lib/ld-linux.so.2 (0xf76fa000)
[little:aterlo] $ ../Downloads/fossil-src-1.33/fossil pull
Pull from https://eas@<redacted>/
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 390 received: 553 ip: <redacted>
[little:aterlo] $

i.e. success on all fronts, I think. You'd then just need to fix up your
Makefile to figure out dynamically whether to include the static or shared
libssl and libcrypto.
Eric Rubin-Smith
2015-06-11 02:01:58 UTC
Permalink
Post by Eric Rubin-Smith
-LIB = -m32 -L1/lib -lssl -lcrypto -lz -ldl -lm
+LIB = -m32 -L1/lib /usr/lib/i386-linux-gnu/libssl.a
/usr/lib/i386-linux-gnu/libcrypto.a -lz -ldl -lm
I suppose this is sexier:

LIB = -m32 -L1/lib -Wl,-static -lssl -lcrypto -Wl,-Bdynamic -lz -ldl -lm

anyway, you get the drift.
Konstantin Khomoutov
2015-06-11 13:48:50 UTC
Permalink
On Wed, 10 Jun 2015 16:42:41 -0400
Post by Richard Hipp
Post by Eric Rubin-Smith
# apt-get install libssl-dev
That seemed to work. Thanks. I can now do the build with
"./configure --static --disable-lineedit". (The --disable-lineedit
was necessary because apparently only the GNU readline package insists
on being dynamically linked.)
The new build is now on the website.
There are alternatives. I know of [1] and [2] at least.

IANAL, but [1] looks like it would be possible to ship its complete
source code with fossil and build it directly in, when requested.

1. https://github.com/antirez/linenoise
2. http://thrysoee.dk/editline/
Richard Hipp
2015-06-11 15:30:07 UTC
Permalink
Post by Konstantin Khomoutov
IANAL, but [1] looks like it would be possible to ship its complete
source code with fossil and build it directly in, when requested.
1. https://github.com/antirez/linenoise
2. http://thrysoee.dk/editline/
Linenoise is included in the Fossil source tree now, and is
automatically compiled into unix builds. See
https://www.fossil-scm.org/fossil/info/851485657643dc2c
--
D. Richard Hipp
***@sqlite.org
Steve Bennett
2015-06-12 15:48:50 UTC
Permalink
Post by Richard Hipp
Post by Konstantin Khomoutov
IANAL, but [1] looks like it would be possible to ship its complete
source code with fossil and build it directly in, when requested.
1. https://github.com/antirez/linenoise
2. http://thrysoee.dk/editline/
Linenoise is included in the Fossil source tree now, and is
automatically compiled into unix builds. See
https://www.fossil-scm.org/fossil/info/851485657643dc2c
--
D. Richard Hipp
You could consider using my fork of linenoise: https://github.com/msteveb/linenoise
This is the version used in Jim Tcl.
It includes support for Windows (and utf8, but you probably don’t care about that)

Cheers,
Steve

--
Embedded Systems Specialists - http://workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: +61 434 921 300
E: ***@workware.net.au F: +61 7 3391 6002

Warren Young
2015-06-10 20:44:37 UTC
Permalink
Post by Richard Hipp
Seems like somebody said that there are issues
with openssl that prevent it from being statically linked.
I don’t know about that, but the last few times I’ve built Fossil on a freshly-installed system sans libssl, the configure script errored out, even if you gave the flag to tell it not to even try to build with SSL.

This configure check should treat “missing headers/libraries” as an implicit request to build without SSL support.
Michal Suchanek
2015-06-11 15:39:14 UTC
Permalink
Hello,
Post by Richard Hipp
Post by Eric Rubin-Smith
If you are worried that some people don't want the bloat of openssl in
their base fossil, perhaps provide both options on the site?
It's not a question of bloat, its a question of whether or not we
require the user to have previously done "apt-get install openssl
libssl" (or whatever other magic incantation is required to get the
right shared libraries running).
I guess I had assumed you could bake it in statically. Is that a non-option
for yall?
There is certainly one issue to be aware of.

When you link dynamically with libssl then your distribution is
responsible for updating libssl in response to libssl vulnerabilities.

When you link statically with libssl you are responsible yourself for
producing an updated build every time a security fix is applied to
libssl regardless of any (lack of) changes in the fossil code.

Thanks

Michal
Richard Hipp
2015-06-11 15:52:19 UTC
Permalink
Post by Michal Suchanek
When you link dynamically with libssl then your distribution is
responsible for updating libssl in response to libssl vulnerabilities.
Yes. On the other hand, Fossil only uses libssl on the client side.
And client-side SSL has far fewer and less severe vulnerabilities than
server-side. So even if vulnerabilities are discovered and you do not
update, you are probably still ok.
--
D. Richard Hipp
***@sqlite.org
Jan Nijtmans
2015-06-12 10:01:57 UTC
Permalink
Post by Richard Hipp
Post by Michal Suchanek
When you link dynamically with libssl then your distribution is
responsible for updating libssl in response to libssl vulnerabilities.
Yes. On the other hand, Fossil only uses libssl on the client side.
And client-side SSL has far fewer and less severe vulnerabilities than
server-side. So even if vulnerabilities are discovered and you do not
update, you are probably still ok.
There are two more practical problems why fossil must link
with static libssl for the Linux downloadable executable.
1) A dynamic libssl will - in turn - be linked with a dynamic libz.
Because fossil includes a static libz as well, this opens the
hole of possible symbol conflicts. As long as the libz versions
are close enough (I think >=1.2.5 is OK) this wouldn't cause
problems, but internal changes in future libz versions could
easily break that. Conclusion: if fossil links with dynamic libssl,
it should link with dynamic libz as well.
2) Different linux distributions use a different library name for
libssl/libcrypto.
e.g. Fedora: libssl.so.10 -> libssl.so.1.0.2
Ubuntu: libssl.so.1 -> libssl.so.1.0.1
So it is impossible to build a fossil binary with works on both
Fedora and Ubuntu if libssl is linked dynamically.

I don't see any other solution than linking libssl statically. Of course,
Fedora and Ubuntu have the option to provide their own fossil binary,
which links with both libz and libssl dynamically. But such a
build will be Fedora/Ubuntu-specific, and is not guaranteed to
work on any other Linux distribution. I don't expect sqlite.org
to provide downloads for each and every Linux distribution .....

Regards,
Jan Nijtmans
Continue reading on narkive:
Loading...