[MinGW-notify] [ mingw-Patches-3158453 ] Handle authenticating proxies

[SF/projects/mingw n. l. <min...@li...>]

Patches item #3158453, was opened at 2011-01-14 12:49
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3158453&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mingw-get
Group: None
Status: Open
Resolution: Remind
Priority: 3
Private: No
Submitted By: Scott Michel (pingbak)
Assigned to: Keith Marshall (keithmarshall)
Summary: Handle authenticating proxies

Initial Comment:
This is a quick and dirty patch to handle authenticating HTTP proxies when mingw-get downloads files. This may not be the right logical or stylistic place to handle proxy authentication, but at least it's saving me time from having to d/l packages manually from behind a corporate firewall.

----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2011-12-05 03:59

Message:
Scott,

Curious that you jump on the secondary issue, while completely ignoring the
(much more critical) primary.

Of course, I would prefer not to have to develop a replacement for the
Microsoft API.  However, that API is rather antisocial within a console
application, and since solving the secondary issue would eliminate the
primary, it may be worth considering.

Neither issue is particularly pressing, right now, which is why I'm leaving
this ticket open as a reduced priority reminder; I will need to address it,
eventually, one way or another.

----------------------------------------------------------------------

Comment By: Scott Michel (pingbak)
Date: 2011-12-02 18:46

Message:
Keith:

Unless you really want a password prompt function that has to hide and
handle user input, it's probably better to let the Windows API do what it
was designed to do. Out does pop up a window to prompt for a user name and
password, which is much less headache from maintainability and security
perspectives.

I agree that the current solution is sub-optimal, but does the project
really want to maintain a password
 prompt user input method, with all of the security headaches that go along
with another potential attack vector?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-12-02 08:31

Message:
Specifically, those issues noted in the referenced bug ticket; primarily
the gratuitous use of GetConsoleWindow(), which I haven't yet adequately
addressed, and (less critically) the somewhat antisocial delegation of
function from a console application to a GUI style pop-up window.

----------------------------------------------------------------------

Comment By: Scott Michel (pingbak)
Date: 2011-12-01 18:07

Message:
What issues, specifically?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-12-01 07:36

Message:
I'd prefer to keep it open; there are a couple of outstanding issues
related to it, and I'd like to preserve this reminder -- I've reset the
resolution code accordingly.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2011-12-01 07:20

Message:
Keith, should this close?

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-03-17 09:45

Message:
This patch relates to MinGW-Bug 3147803:
https://sourceforge.net/tracker/?func=detail&aid=3147803&group_id=2435&atid=102435

I'll keep this ticket open, while I progress it, but I suggest that we keep
any follow-up discussion on the original bug ticket.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2011-02-09 05:09

Message:
Scott,

Thank you for you patch; I will review when I have time.

Please note that assignment of priority is the prerogative of project
administrators and/or ticket assignee; as submitter, and belonging in
neither of these categories, it is not yours.  FWIW, your attempt to
escalate priority has a negative effect, for I work to a schedule of
"effective priorities", where the effective priority is computed
algorithmically:

if priority assigned by administrator or assignee
then effective-priority = assigned-priority
else effective-priority = 2 * median-priority - assigned-priority

which, in this case becomes 2 * 5 - 7 = 3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=3158453&group_id=2435