Thanks for the additional testing.
Uploaded.
Cheers!
Sylvain
On 17/05/2021 12:39, Ola Lundqvist wrote:
Hi again
I was able to reproduce the issue and I can confirm that it is solved
by the update.
On an unfixed version I run the following:
curl -L -e ";auto" -raw -v
Hi again
I was able to reproduce the issue and I can confirm that it is solved by
the update.
On an unfixed version I run the following:
curl -L -e ";auto" -raw -v http://test:p...@inguza.com/'
And the resulting Referer output was:
> Referer: http://test:p...@inguza.com/
With the fixed
Hi Sylvain
I have done some regression testing and it looks fine.
I'll try to reproduce the actual issue too.
// Ola
On Mon, 17 May 2021 at 11:09, Sylvain Beucler wrote:
> Hi,
>
> I thought you'd rebuild but here you go.
>
> I intend to upload today.
>
> Cheers!
> Sylvain
>
> On 17/05/2021
Hi,
I thought you'd rebuild but here you go.
I intend to upload today.
Cheers!
Sylvain
On 17/05/2021 08:13, Ola Lundqvist wrote:
Hi again Sylvain
Today I was about to test the packages but I realize that I only have a
libcurl-doc deb file to test.
Will you upload the rest for testing
Hi again Sylvain
Today I was about to test the packages but I realize that I only have a
libcurl-doc deb file to test.
Will you upload the rest for testing too?
// Ola
On Sun, 16 May 2021 at 09:08, Ola Lundqvist wrote:
> Hi
>
> I have reviewed the changes and it looks good.
> I'll see if I
Hi
I have reviewed the changes and it looks good.
I'll see if I can get some time to perform any relevant tests too.
// Ola
On Sat, 15 May 2021 at 23:34, Sylvain Beucler wrote:
> Hi Ola,
>
> You can check the LTS version at:
> https://www.beuc.net/tmp/debian-lts/curl/
>
> I followed the
Hi Ola,
You can check the LTS version at:
https://www.beuc.net/tmp/debian-lts/curl/
I followed the method from Ubuntu and SUSE and backported the URL API
for LTS and ELTS, plus the new test case for the CVE.
I'm currently diffing the test suite results, cf. my notes at:
Hi Sylvain
Great! Let me know if you want help with review, testing or something else.
// Ola
On Sat, 15 May 2021 at 23:18, Sylvain Beucler wrote:
> Hi,
>
> I claimed it yesterday and my work is mostly done.
>
> Cheers!
> Sylvain
>
> On 15/05/2021 23:11, Ola Lundqvist wrote:
> > Hi Utkarsh
>
Hi,
I claimed it yesterday and my work is mostly done.
Cheers!
Sylvain
On 15/05/2021 23:11, Ola Lundqvist wrote:
Hi Utkarsh
I have looked into your patch and I think it looks good. I do not fully
understand why all the changes in url.c were done but I think it looks
fine anyway.
The risk
Hi Utkarsh
I have looked into your patch and I think it looks good. I do not fully
understand why all the changes in url.c were done but I think it looks fine
anyway.
The risk of regression should be small.
Do you want me to do the update, or do you want to do it yourself?
Or do you think we
Hi Utkarsh, all
I have done some more investigation on this matter. I have checked the
statement from upstream that we can re-use some existing strip code to
remove the strings this way.
The thing is that I cannot find any code that do URL stripping so that is
not really a viable option. This
Hi Utkarsh, all
After reading the description of this CVE again I realize that I
misunderstood the description last time.
The problem is that the "referrer" header is not stripped.
This changes my conclusion to some extent.
I see no problem with fixing this issue from a regression point of
Hi Utkarsh, all
Is this even a vulnerability?
The problem is that authentication information is not stripped if the
browser is redirected to another place.
If you trust a site enough to provide authentication data, I guess you also
trust that if that site happens to be relocated you should also
Hello,
[CCing the Security team in case they have some ideas or suggestions
for CVE-2021-22876/curl]
Whilst triaging and looking thoroughly for this CVE, affecting curl, I
noticed that the upstream patch uses elements like CURLU,
CURLUPART_{URL,FRAGMENT,USER,PASSWORD}. This comes from the URL
14 matches
Mail list logo
