Re: [Bug-wget] Can't build wget with GnuTLS on Mac OS X

[Tim Rühsen]

Am Sonntag, 6. Dezember 2015, 12:48:45 schrieb 桃源老師:
> Hello, Tim-san,
> 
> > 2015/12/06 7:47 A.M. Tim Rühsen  wrote:
> > 
> > Am Sonntag, 6. Dezember 2015, 01:29:17 schrieb 桃源老師:
> >> my configure statement:
> >> $ export TARGET ="/Volumes/ffmpeg_compile"
> >> $ LDFLAGS=-L${TARGET}/lib LIBS=-lgmp  ./configure --prefix=${TAREGT}
> > 
> > Is this correct ?
> > --prefix=${TAREGT}
> > 
> > Maybe TARGET ?
> 
> Sorry it's my typo error...
> 
> > "_wrap_nettle_pk_generate_params in libgnutls.a(pk.o)"
> > You statically link  GnuTLS ? Try it dynamically, else you need libnettle
> > linked *after* libgnutls.
> 
> Well, now I can build wget with dynamically linked GnuTLS.
> 
> But if I can, I'd like to have a statically linked one.  You mentioned that
> "need libnettle linked after libgnutls", but I don't know how should I.
> Could you please provide the way to build statically linked binary of wget?

IMO, it's a bad idea... (and I have not much experience with that), please 
read http://www.akkadia.org/drepper/no_static_linking.html and reconsider 
before reading on.


If wget links dynamically, you can 'ldd wget' to see all the libraries need 
for static linking. You have to figure out the order on the command line 
yourself. Gcc option -static is helpful (tells the linker to use static .a 
libraries instead of dynamic .so - if static ones are available).

Just modify/extend your original command line:
gcc  -I/Volumes/ffmpeg_compile/include -DHAVE_LIBGNUTLS -
I/Volumes/ffmpeg_compile/include -DNDEBUG   -L/Volumes/ffmpeg_compile/lib -o 
wget connect.o convert.o cookies.o ftp.o css_.o css-url.o ftp-basic.o ftp-ls.o 
hash.o host.o hsts.o html-parse.o html-url.o http.o init.o log.o main.o 
netrc.o progress.o ptimer.o recur.o res.o retr.o spider.o url.o warc.o utils.o 
exits.o build_info.o   version.o ftp-opie.o gnutls.o http-ntlm.o 
../lib/libgnu.a /Volumes/ffmpeg_compile/lib/libiconv.a  -lnettle -
L/Volumes/ffmpeg_compile/lib -lgnutls -L/Volumes/ffmpeg_compile/lib -lz -lgmp

gnutls is using nettle functions, so here the order is wrong. Link nettle 
after gnutls, followed by gmp. 

Be warned that your executable might be huge after linking.

Also, it might be that you need a different C standard library for static 
linking, just search the net for detailed infos.

Tim


signature.asc
Description: This is a digitally signed message part.

Re: [Bug-wget] Can't build wget with GnuTLS on Mac OS X

[桃源老師]

Hello Tim-san,

> 2015/12/06 7:59 P.M. Tim Rühsen  wrote:

>> But if I can, I'd like to have a statically linked one.  You mentioned that
>> "need libnettle linked after libgnutls", but I don't know how should I.
>> Could you please provide the way to build statically linked binary of wget?
> 
> IMO, it's a bad idea... (and I have not much experience with that), please 
> read http://www.akkadia.org/drepper/no_static_linking.html and reconsider 
> before reading on.

Thanks for explanation.  I now understand why wget provides dynamic linking 
only.

Also, I learned that Mac OS X does not support GCC option "-static".  Apple 
supports statically linked binary but don't support static binary.  (I get so 
many another error)

Now I installed wget and related libraries, binaries, etc to default place 
(/usr/local).


Thanks for co-operation.

Best Regards,


// Miya aka. TougenRoushi



smime.p7s
Description: S/MIME cryptographic signature

[Bug-wget] [bug #46620] NULL Point Dereference casing SegFault in hsts_hash_func in 1.17

[Claudio Guarnieri]

Follow-up Comment #2, bug #46620 (project wget):

Here, hope it helps.
Apologies for the typos in the original message.

$ gdb --args ./wget https://godzilla.seedboxes.cc
(gdb) r
Starting program: /tmp/wget-1.17/src/wget https://godzilla.seedboxes.cc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
--2015-12-06 23:59:22--  https://godzilla.seedboxes.cc/
Resolving godzilla.seedboxes.cc... 188.122.93.226, 2a00:1630:44:803::1
Connecting to godzilla.seedboxes.cc|188.122.93.226|:443... connected.
HTTP request sent, awaiting response... 200 OK

Program received signal SIGSEGV, Segmentation fault.
0x00418541 in hsts_hash_func (key=0xb98720) at hsts.c:95
95for (h = k->host; *h; h++)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] Fixed: darnir/wget#53 (master - b0d2fa5)

[Travis CI]

Build Update for darnir/wget
-

Build: #53
Status: Fixed

Duration: 11 minutes and 30 seconds
Commit: b0d2fa5 (master)
Author: Darshit Shah
Message: Introduce Travis Integration

* .travis.yml: Configuration file for Travis-CI
* contrib/travis-ci: Script to run on travis. Similar to check-hard but modified
  for travis.
* tests/valgrind-suppressions{-ssl}: Add extra suppressions to prevent a
Valgrind False Positive errors in an old version

Since Travis currently supports only public repositories on GitHub, the support
for automated testing through Travis will be done using my Clone of Wget on
GitHub at: https://github.com/darnir/wget.git
Any commits pushed to this repository will trigger a build on Travis.

View the changeset: 
https://github.com/darnir/wget/compare/2cfcadf5e6d5...b0d2fa574871

View the full build log and details: 
https://travis-ci.org/darnir/wget/builds/95233496

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[Bug-wget] Fwd: New Defects reported by Coverity Scan for GNU Wget

[Darshit Shah]

-- Forwarded message --
From:  
Date: 6 December 2015 at 22:39
Subject: New Defects reported by Coverity Scan for GNU Wget
To: dar...@gmail.com



Hi,

Please find the latest report on new defect(s) introduced to GNU Wget
found with Coverity Scan.

6 new defect(s) introduced to GNU Wget found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 6 of 6 defect(s)


** CID 1341706:(RESOURCE_LEAK)
/src/ftp.c: 1518 in getftp()
/src/ftp.c: 1528 in getftp()
/src/ftp.c: 1518 in getftp()
/src/ftp.c: 1518 in getftp()



*** CID 1341706:(RESOURCE_LEAK)
/src/ftp.c: 1518 in getftp()
1512 logputs (LOG_NOTQUIET, "Server does not want to
resume the SSL session. Trying with a new one.\n");
1513   if (!ssl_connect_wget (dtsock, u->host, NULL))
1514 {
1515   fd_close (csock);
1516   fd_close (dtsock);
1517   logputs (LOG_NOTQUIET, "Could not perform SSL
handshake.\n");
>>> CID 1341706:(RESOURCE_LEAK)
>>> Variable "fp" going out of scope leaks the storage it points to.
1518   return CONERROR;
1519 }
1520 }
1521   else
1522 logputs (LOG_NOTQUIET, "Resuming SSL session in data
connection.\n");
1523
/src/ftp.c: 1528 in getftp()
1522 logputs (LOG_NOTQUIET, "Resuming SSL session in data
connection.\n");
1523
1524   if (!ssl_check_certificate (dtsock, u->host))
1525 {
1526   fd_close (csock);
1527   fd_close (dtsock);
>>> CID 1341706:(RESOURCE_LEAK)
>>> Variable "fp" going out of scope leaks the storage it points to.
1528   return CONERROR;
1529 }
1530 }
1531 #endif
1532
1533   /* Get the contents of the document.  */
/src/ftp.c: 1518 in getftp()
1512 logputs (LOG_NOTQUIET, "Server does not want to
resume the SSL session. Trying with a new one.\n");
1513   if (!ssl_connect_wget (dtsock, u->host, NULL))
1514 {
1515   fd_close (csock);
1516   fd_close (dtsock);
1517   logputs (LOG_NOTQUIET, "Could not perform SSL
handshake.\n");
>>> CID 1341706:(RESOURCE_LEAK)
>>> Variable "fp" going out of scope leaks the storage it points to.
1518   return CONERROR;
1519 }
1520 }
1521   else
1522 logputs (LOG_NOTQUIET, "Resuming SSL session in data
connection.\n");
1523
/src/ftp.c: 1518 in getftp()
1512 logputs (LOG_NOTQUIET, "Server does not want to
resume the SSL session. Trying with a new one.\n");
1513   if (!ssl_connect_wget (dtsock, u->host, NULL))
1514 {
1515   fd_close (csock);
1516   fd_close (dtsock);
1517   logputs (LOG_NOTQUIET, "Could not perform SSL
handshake.\n");
>>> CID 1341706:(RESOURCE_LEAK)
>>> Variable "fp" going out of scope leaks the storage it points to.
1518   return CONERROR;
1519 }
1520 }
1521   else
1522 logputs (LOG_NOTQUIET, "Resuming SSL session in data
connection.\n");
1523

** CID 1341705:  Security best practices violations  (TOCTOU)
/src/hsts.c: 479 in hsts_store_open()



*** CID 1341705:  Security best practices violations  (TOCTOU)
/src/hsts.c: 479 in hsts_store_open()
473
474   if (file_exists_p (filename))
475 {
476   if (stat (filename, ) == 0)
477 store->last_mtime = st.st_mtime;
478
>>> CID 1341705:  Security best practices violations  (TOCTOU)
>>> Calling function "fopen" that uses "filename" after a check function. 
>>> This can cause a time-of-check, time-of-use race condition.
479   fp = fopen (filename, "r");
480   if (!fp || !hsts_read_database (store, fp, false))
481 {
482   /* abort! */
483   hsts_store_close (store);
484   xfree (store);

** CID 1273467:  API usage errors  (BUFFER_SIZE)
/lib/md5.c: 291 in md5_process_bytes()



*** CID 1273467:  API usage errors  (BUFFER_SIZE)
/lib/md5.c: 291 in md5_process_bytes()
285   memcpy (&((char *) ctx->buffer)[left_over], buffer, len);
286   left_over += len;
287   if (left_over >= 64)
288 {
289   md5_process_block (ctx->buffer, 64, ctx);
290   left_over -= 64;
>>> CID 1273467:  API usage errors  (BUFFER_SIZE)
>>> The source buffer ">buffer[16]" potentially overlaps with the 
>>> destination buffer "ctx->buffer", 

Re: [Bug-wget] Travis-CI updates and minor bug fixes

[Darshit Shah]

On 12/04, Tim Rühsen wrote:

Looks good, go ahead !


Pushed! The first success email should have reached the list (or may take more 
time due to moderation)




Tim

On Thursday 03 December 2015 18:55:27 Darshit Shah wrote:

Now that --without-ssl works again, I thought it'd be a good time to finish
Travis too.

Attached is an updated patch. Along with my other pending patch for fixing
the test suite, this works perfectly and all tests currently pass.

As mentioned earlier, multicolumn character languages still have a bug. I
will debug that as soon as I get some time. Till then, the test suite works
only on the C locale.

I'd like to push this as soon as possible.

On 11/18, Tim Rühsen wrote:
>Hi Darshit,
>
>great work !
>
>The Travis yml file is much cleaner than the ones that I use :-)
>
>There is a small type: 'suppresion' should be 'suppression' (in the
>valgrind suppression files).
>
>Regards, Tim
>
>On Wednesday 18 November 2015 00:17:41 Darshit Shah wrote:
>> It's been a while since I shared these patches. The fixes to make
>> distcheck
>> went in before the last release, however, we still don't have Travis
>> integration. The API Tim linked to is valid only for private builds which
>> is a paid feature of Travis.
>>
>> Since the Turkish tests were failing due to a bad translation, I've
>> currently removed it from the list of languages. Once we have the
>> translation fixed, we can add the Turkish language back into the tests.
>> I'd
>> like to have that language in because of the specific corner case
>> provided
>> in its character set.
>>
>> Apart from that, I randomly picked and added Japanese against a language
>> to
>> test against. This was chosen because it has multi-byte and multi-column
>> characters and I want to ensure that the progress bar works perfectly for
>> these. Turns out in one particular case it doesn't. Which is why the
>> current Travis setup fails too. Hence, I removed the language for now so
>> that we have a working Travis setup. However, that was a valid bug and we
>> need to look into fixing it.
>>
>> Currently, the only build that fails is one with --without-ssl. While I
>> understand that this is a ridiculous idea in this day, but we provide a
>> configure option to build without SSL and should support it. I've left it
>> there since it's a more major issue we need to look into before the next
>> minor release.
>>
>> Email notifications from Travis are not currently working. I will discuss
>> this on IRC with them tomorrow to see how we can fix this.
>>
>> I've attached the new patch for Travis integration and will push it if no
>> one complains.
>>
>> Eventually, I'd like to extend this travis file to cover OSX builds too.
>> But currently, the OSX environment seems to have some problems with
>> Python that requires some manual work. Hence, I've not included the OSX
>> as a target OS for testing in this patch.
>>
>> On 10/11, Tim Rühsen wrote:
>> >Am Sonntag, 11. Oktober 2015, 12:32:14 schrieb Darshit Shah:
>> >> However, I did come across a small problem. Travis currently accepts
>> >> open source build requests from GitHub only. So I don't think we can
>> >> use it from Savannah. Would it be a problem if we pushed the
>> >> .travis.yml to master and allow the builds to be fired from one of our
>> >> GitHub clones?
>> >
>> >Hi Darshit,
>> >
>> >IMO there is no problem.
>> >
>> >If there is no possibility to trigger a build from Savannah, we have to
>> >use
>> >Github. Or we have to trigger it manually...
>> >
>> >That is something that other people already asked for:
>> >http://kamranicus.com/blog/2015/03/29/triggering-a-travis-build-programm
>> >ati
>> >cally/
>> >
>> >Maybe you could give this a try (maybe using wget instead of curl ?).
>> >http://docs.travis-ci.com/user/triggering-builds/
>> >
>> >Regards, Tim


--
Thanking You,
Darshit Shah


signature.asc
Description: PGP signature

[Bug-wget] [bug #46620] NULL Point Dereference casing SegFault in hsts_hash_func in 1.17

[Claudio Guarnieri]

URL:
  

 Summary: NULL Point Dereference casing SegFault in
hsts_hash_func in 1.17
 Project: GNU Wget
Submitted by: nex
Submitted on: Sun 06 Dec 2015 10:54:20 PM GMT
Category: Crash/Freeze/Infloop
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.17
Operating System: GNU/Linux
 Reproducibility: Every Time
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: No

___

Details:

While making some requests to a site with SSL/TLS transport enabled, I'm
experiencing repeated segmentation faults with version 1.17, both compiled
manually as well as packaged in Debian testing.

I am able to reproduce it at every execution, and others experienced the same
issue with compiled 1.17 on Ubuntu.

[code]#0  0x00418541 in hsts_hash_func (key=0xb989b0) at hsts.c:95
#1  0x0041695c in find_cell (ht=0x69f470, key=0xb989b0) at hash.c:321
#2  0x00416d4e in hash_table_remove (ht=0x69f470, key=0xb989b0) at
hash.c:454
#3  0x004189dc in hsts_remove_entry (store=0x682970, kh=0xb989b0) at
hsts.c:239
#4  0x00418f6a in hsts_store_entry (store=0x682970,
scheme=SCHEME_HTTPS,
host=0x682e50 "[REDACTED]", port=0, max_age=0, include_subdomains=true) at
hsts.c:425
#5  0x004223aa in gethttp (u=0x69f370, hs=0x7fffde50,
dt=0x7fffe1a4, proxy=0x0,
iri=0x680a40 , count=1) at http.c:3405
#6  0x00423a59 in http_loop (u=0x69f370, original_url=0x69f370,
newloc=0x7fffdfe8,
local_file=0x7fffdfd8, referer=0x0, dt=0x7fffe1a4, proxy=0x0,
iri=0x680a40 ) at http.c:3979
#7  0x00432b7d in retrieve_url (orig_parsed=0x69f370,
origurl=0x69f3e0 "https://[REDACTED];, file=0x7fffe1b0,
newloc=0x7fffe1a8, refurl=0x0, dt=0x7fffe1a4,
recursive=false, iri=0x680a40 , register_status=true) at
retr.c:817
#8  0x0042bc5b in main (argc=2, argv=0x7fffe388) at
main.c:1860[/code]




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bug-wget] [bug #46620] NULL Point Dereference casing SegFault in hsts_hash_func in 1.17

[Darshit Shah]

Follow-up Comment #1, bug #46620 (project wget):

If you're seeing repeated and reproduceable issue, would you please provide an
example command line that shows the issue?

Such examples are often very useful in identifying the use case and program
path. 

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/