[Touch-packages] [Bug 1914481] Re: use the size of the data when determing the server response

2021-02-05 Thread Brian Murray
** Description changed: - whoopsie's server_response code is using "g_string_append" instead of - "g_string_append_len" which has the knock on effect of sending too much - data to its "handle_response". This ends up being a problem if the daisy - servers are running on Ubuntu 18.04 instead of

[Touch-packages] [Bug 1914481] Re: use the size of the data when determing the server response

2021-02-05 Thread Brian Murray
** Description changed: whoopsie's server_response code is using "g_string_append" instead of "g_string_append_len" which has the knock on effect of sending too much data to its "handle_response". This ends up being a problem if the daisy servers are running on Ubuntu 18.04 instead of

[Touch-packages] [Bug 1914481] Re: use the size of the data when determing the server response

2021-02-04 Thread Launchpad Bug Tracker
** Branch linked: lp:whoopsie -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1914481 Title: use the size of the data when determing the server response Status in

[Touch-packages] [Bug 1914481] Re: use the size of the data when determing the server response

2021-02-04 Thread Steve Beattie
For fixing this via an SRU for focal and groovy, the Ubuntu Security team is okay with the result of this going to the security pocket, assuming the update is built in a ppa where only security updates are enabled. Thanks! -- You received this bug notification because you are a member of Ubuntu

[Touch-packages] [Bug 1914481] Re: use the size of the data when determing the server response

2021-02-04 Thread Launchpad Bug Tracker
This bug was fixed in the package whoopsie - 0.2.75 --- whoopsie (0.2.75) hirsute; urgency=medium * src/whoopsie.c: modify server_response() so that it does not incorrectly assume that data is null-terminated and actually use the size of the data. (LP: #1914481) -- Brian