Opened 8 years ago

Closed 8 years ago

#4748 closed enhancement (fixed)

gnutls-3.2.12.1

Reported by: Fernando de Oliveira Owned by: ken@…
Priority: normal Milestone: 7.6
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description (last modified by ken@…)

ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.12.tar.xz

I have seen a report that p11-kit needs to be newer, but I'm not yet sure if that affects BLFS. Will test.

Change History (9)

comment:1 by ken@…, 8 years ago

Description: modified (diff)
Owner: changed from blfs-book@… to ken@…
Status: newassigned
Summary: gnutls-3.2.12gnutls-3.2.12.1

Updated to 3.2.12.1 to revert an ABI change in 3.2.12.

These fix CVE-2014-0092 :

A vulnerability was discovered that affects the certificate verification functions of all gnutls versions. A specially crafted certificate could bypass certificate validation checks. The vulnerability was discovered during an audit of GnuTLS for Red Hat.

comment:2 by ken@…, 8 years ago

For gnome, this builds with our current p11-kit. Tested in epiphany, https:// with a good certificate still works. Also measured, but my times for check and rebuilding the API docs are considerably slower than what is in the book, and it looks as if 'check' on a _slow_ machine might use less SBUs (several pauses during the tests). Instructions same as for 3.11.

comment:3 by ken@…, 8 years ago

Also builds fine on an xfce system without p11-kit : never trust that reports, even from a reliable source, indicate what will happen on a different system.

I also note that _nothing_ appears to link directly to gnutls, but I suppose that something is opening the lib(s) dynamically.

comment:4 by ken@…, 8 years ago

Fixed in r12828, I'll keep this open until I've built a fresh system with gnome, just in case there are any consequential fixes required. If I don't do that, something is bound to break.

comment:5 by Fernando de Oliveira, 8 years ago

I think we are giving numbers to different things. Not questioning what you have done. I am working now on these numbers, so that you can tell me how to better name them.

comment:6 by Fernando de Oliveira, 8 years ago

Normal build, docs installed with

make -C doc/reference install-data-local

Sizes calculated with du -sch ou du -sh. SBU is 180s, and the script just divide difference in $SECONDS after "cd" into source dir until last install is done. After that, script does calculations and determines sizes, but these do not enter in the SBU calculations. Due to the use of "du -sch", 18M + 85M = 102M is understandable due to roundof effect.

18M	/home/fernando/tmp/paco-build-2014.03.06-11h20m28s/DEST-gnutls-3.2.12.1
85M	/home/fernando/tmp/paco-build-2014.03.06-11h20m28s/gnutls-3.2.12
102M	total
5,0M	/home/fernando/sshfs/blfs/gnutls-3.2.12.1.tar.xz
5,0M	total
a795db68253d1336f1e3c2ee48c1fee4  /home/fernando/sshfs/blfs/gnutls-3.2.12.1.tar.xz

SBU_TIME: .84444444

Using the same build, perform the tests (some packages do not like "env LC_ALL=C"):

          cd /home/fernando/tmp/paco-build-2014.03.06-11h20m28s/gnutls-3.2.12
          { time \
            { 
              env LC_ALL=C make -k check
            }
          } 2>&1 | tee -a $LOGDIR/$PACKAGE-make-k-check-$DATE.log

-k is used just for the sake of not having to redo, if some test fail. I have 5 skips, no *fail in this case.

real	5m26.458s
user	1m16.056s
sys	0m24.123s

Tests finished, by hand I determine new sizes:

$ du -sch ../*
18M	 ../DEST-gnutls-3.2.12.1
94M	 ../gnutls-3.2.12
112M	 total

Therefore, by hand, determine for the tests

(5⋅60+26,458)/180   = ((5 ⋅ 60) + 26,458) ∕ 180
≈ 1,8136556

SBU_TIME=1.8136556

112-102=10MB is what is added to dir size.

Now, run complete build, no tests, with switch --enable-gtk-doc, without make -C doc/reference install-data-local, API docs are then rebuilt and installed:

18M	/home/fernando/tmp/paco-build-2014.03.06-11h35m32s/DEST-gnutls-3.2.12.1
88M	/home/fernando/tmp/paco-build-2014.03.06-11h35m32s/gnutls-3.2.12
105M	total
5,0M	/home/fernando/sshfs/blfs/gnutls-3.2.12.1.tar.xz
5,0M	total
a795db68253d1336f1e3c2ee48c1fee4  /home/fernando/sshfs/blfs/gnutls-3.2.12.1.tar.xz

SBU_TIME: .97222222

By hand, determine

0,97222222−0,84444444   = 0,97222222 − 0,84444444
= 0,12777778

105−102   = 105 − 102
= 3

Thus

SBU_TIME added for rebuild: 0.12777778
Dis size added for rebuild: 3MB

With these data, I would add to the book:

Download MD5 sum: a795db68253d1336f1e3c2ee48c1fee4

Download size: 5,0 MB

Estimated disk space required: 102 MB (additional 10 MB for the tests, 3 MB
if rebuilding the API documentation)

Estimated build time: 0.8 SBU (additional 1.8 SBU for the tests and 0.1 SBU
for API documentation rebuild)

I am not worried about small differences, because many are the possible reasons.

But we have two large differences, I would even say discrepancies, it seems that we are giving the same name for different things:

additional 3MB for API rebuilt is necessary in disk (you could have, say 3.5, 2.8. no problem). But "less 1 MB" means we are talking about different things.

additional 0.1 SBU for API rebuilt is necessary (almost nothing) but 1.3 SBU that you gave, also clearly seems to me we are talking about different things.

One thing I do not find important but do not understand is the tarball size that I have 5,0 MB and you 4.9 MB. Most differences in sizes above come from you using 64bit and I using 32bit systems. But "du" gives different values for the same tarball, having the same md5sum, depending on the architecture?

What can be done in order to not confuse ourselves and the readres?

comment:7 by ken@…, 8 years ago

I take the tarball size from ls -lh.

My SBU (tested after booting the new system, i.e. as if using it to build itself) is 140.943 seconds. I don't think that measuring to thousandths of a second is important, it just happens to be how I now do it using 'time'. As you say, 32-bit x86 creates smaller files - it might also take longer to do some compiles because it doesn't have many registers. Anyway, this is what I got:

For measuring, I build by had (in the en_GB.UTF-8 locale) without setting MAKEFLAGS. and use bash's time command to time each command.

  1. without enabling gtk-doc:

configure 35.093s. make 67.474s DESTDIR install 4.099s. DESTDIR docs 0.966s. Total time 107.632 / 140.943 which I rounded up to 0.8 SBU. Space from du -sh : build 99M, DESTDIR 20M.

I then ran make check. Time 286.184 (4m46) which is +2.0 SBU for me, and space increased by 12MB.

  1. with --enable-gtk-doc :

configure 34.756s make 250.163s DESTDIR 4.855s total time 289.774 / 140.943 which I rounded up to 2.1 SBU. Therefore, extra time to regenerate the docs is +1.3 SBU. Space 98M source, which is where the "less 1MB" comes from, and again 20MB installed.

I agree that my figures for rebuilding the docs are very different from yours. At the moment I'm trying to devote all my CPU power to building a gnome system in chroot, so it will be some time before I can have another look at my measurements.

comment:8 by ken@…, 8 years ago

Rebuilt my gnome and xfce desktops with this change. No build breakage (that's to be expected - the breakage only happens when we don't test things).

Remeasured the build of gnutls ABI docs : cannot get close to either the time or space I had for my previous measurements. My current measurements seem close to what Fernando has. I've changed the measurements in r12835.

comment:9 by ken@…, 8 years ago

Resolution: fixed
Status: assignedclosed

Forgot to change the status.

Note: See TracTickets for help on using tickets.