Proxy preferences do not work for HTTPS sites #2249
Comments
|
I uploaded a jar based on commit 38fe410 from 2016-10-16 here: http://www.filedropper.com/jabref-37dev-fat Regarding the other exceptions: Can you please send us your bib file - or at the least the group-meta-data to developers@jabref.org? You can find the meta-data at the bottom of your bib-file if you open the file with a text editor. Thanks! |
matthiasgeiger
added
the
status: waiting-for-feedback
|
Thanks for your report.! Your error is related to the recent Medline changes. The fetcher now uses You must now use the https.proxy.xxx arguments on startup: 2016-11-08 11:07 GMT+01:00 heseber notifications@github.com:
|
|
Okay, thank you, and indeed, adding an https proxy to the call resolved this issue (setting the proxy in the application itself does not help, so I have to leave it in the application as "direct" and I really have to use the command line for specifying the proxy):
Thank you for your help! As for sending my bib file - this is probably not possible because it would contain sensitive information, but I will send the group tree to developers@jabref.org. |
matthiasgeiger
added
bug
|
Thanks for your reply. The simplest solution should be to use the JabRef proxy settings not only for HTTP but also for HTTPS. |
matthiasgeiger
changed the title
|
Okay, but I would still hesitate to use the JabRef configuration as long as the password is stored unencrypted. |
|
@heseber The JabRef proxy settings are now used for http and https and in a few minutes a working version should be available at http://builds.jabref.org/master/ This will also be realized as part of v3.8.1 very soon. |
|
Dear Jörg,
OK, thanks a lot. Are there any plans to use encryption for storing the proxy password? As long as this is not available, I would have to stick to the command line parameters for specifying the proxy instead of using the application preferences.
Thanks also for all the time you invest into JabRef!
Regards
Henrik
Best regards
Henrik
Am 22. Dezember 2016 09:55:27 MEZ, schrieb "Jörg Lenhard" <notifications@github.com>:
…
@heseber The JabRef proxy settings are now used for http and https and
in a few minutes a working version should be available at
http://builds.jabref.org/master/
This will also be realized as part of v3.8.1 very soon.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2249 (comment)
--
Dr. Henrik Seidel, Grenobler Ring 16, 13127 Berlin
Tel. +49 30 4448650, Mobile +49 1522 8650172
|
|
@heseber There are currently no plans for storing the proxy password in an encrypted fashion (that I am aware of). And to be fair @matthiasgeiger did all the actual work, I just clicked a few buttons to integrate it into JabRef ;-) |
|
Do you delete the command line history?
Where should the decryption key be stored? JabRef source? Do you want to
enter your decryption password each time? Do you use a password manager?
Am 22.12.2016 10:11 schrieb "Jörg Lenhard" <notifications@github.com>:
… @heseber <https://github.com/heseber> There are currently no plans for
storing the proxy password in an encrypted fashion (that I am aware of).
And to be fair @matthiasgeiger <https://github.com/matthiasgeiger> did
all the actual work, I just clicked a few buttons to integrate it into
JabRef ;-)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2249 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABTafrQPbCmYwBQ3eVAL8CHXzCT2dicoks5rKj6xgaJpZM4KsPjI>
.
|
|
Hello,
When specifying the proxy on the command line, on Windows I do not have to specify the password. This is taken from the system. So I do not have to delete the command line history.
I don't want to reenter the password for every search, of course. So one option is to ask for the password once per session and keep it in memory until the end of the session, ideally also encrypted to be protected against memory spoofing. A password safe is also a possible solution, but this would require entering a master password at the beginning of the session as well, so I cannot see an advantage for the user compared to entering the password directly. Storing the encrypted password without a master password wouldn't be safe. In summary, the best solution would probably to ask for the password at the beginning of a session at first internet access and to store the password in encrypted fashion in memory until the application is closed. The encryption key should not be hard coded in the source code but should be generated in a session specific manner as well from a random number generator.
What do you think?
Regards
Henrik
Am 22. Dezember 2016 10:13:39 MEZ, schrieb Oliver Kopp <notifications@github.com>:
…Do you delete the command line history?
Where should the decryption key be stored? JabRef source? Do you want
to
enter your decryption password each time? Do you use a password
manager?
Am 22.12.2016 10:11 schrieb "Jörg Lenhard" ***@***.***>:
> @heseber <https://github.com/heseber> There are currently no plans
for
> storing the proxy password in an encrypted fashion (that I am aware
of).
>
> And to be fair @matthiasgeiger <https://github.com/matthiasgeiger>
did
> all the actual work, I just clicked a few buttons to integrate it
into
> JabRef ;-)
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
>
<#2249 (comment)>,
or mute
> the thread
>
<https://github.com/notifications/unsubscribe-auth/ABTafrQPbCmYwBQ3eVAL8CHXzCT2dicoks5rKj6xgaJpZM4KsPjI>
> .
>
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2249 (comment)
--
Dr. Henrik Seidel, Grenobler Ring 16, 13127 Berlin
Tel. +49 30 4448650, Mobile +49 1522 8650172
|
|
Dear Henrik, Thanks for your suggestion. I think this is a valuable discussion, even if my opinion and conclusions are diametrically different to yours. We also have discussed this internally a number of times.
I need to emphasize that the following is just my personal opinion. To me personally, the problem you describe is a secondary concern, or rather a tertiary / quartenary / quinary / etc. I will keep my effort focused on improving the actual features of JabRef and not a perceived vulnerability. I have taken my fair share of courses in information security and understand the problems. Peoples machines will get compromised not because some malicious attacker investigates the heap of a running JabRef, but because they visit strange websites and download dubious files, or because a download site is hacked and someone attaches malware to otherwise ordinary software. JabRef is simply too insignificant, with too few users, to even consider investing the time in understanding how to hack it. This is not at all a proper solution of course. I would like to have a secure and usable JabRef. But in the light of our very very limited resources and the other features we would like to implement, this is just an ugly practical tradeoff of priorities. I would gladly support an encryption mechanism if, oh if only there was a library that was not an utter pain in the ass to use. If the security people want software to become more secure, I would appreciate if they invested more time into building usable security (something that is slowly emerging) instead of more clever encryption schemes. Lastly, the situation can be changed of course: I fully understand if someone considers this a major problem based on his personal preferences and I would be very happy if a person steps forward and implements a nice solution that does not annoy 99% of the remaining users of JabRef. Thus, I encourage you @heseber to implement a proposal and add a pull request. We can then work towards a solution that works for everyone. Regards |
|
Dear Jörg,
thank you again for all your work which is really highly appreciated. Unfortunately, although I contributed to some open source projects when I was a student, nowadays I am missing the time for continuing such activities, unfortunately.
In a corporate environment, storing a password in clear text on a disk drive is simply not an option - this password is used for single-sign-on, so the password is used for many purposes, such as human resources, protecting company intellectual property, ...
I'd agree that if someone is able to create a memory dump and to scan it for passwords, then we have a more serious problem, so encrypting the password in memory might be a bit overdone. And if encryption is too difficult to implement after all, it would be helpful to at least allow the user to enter only the user name for the proxy authentication (in the application settings) and to leave the password field empty. The application should then ask for the password interactively when it is first needed (and keep it in memory until the application is closed). Would that be something that could be implemented without too much effort?
Happy new year, by the way.
Best regards
Henrik
… Jörg Lenhard ***@***.***> hat am 22. Dezember 2016 um 11:49 geschrieben:
Dear Henrik,
Thanks for your suggestion. I think this is a valuable discussion, even if my opinion and conclusions are diametrically different to yours. We also have discussed this internally a number of times.
> >
> What do you think?
>
> >
I need to emphasize that the following is just my personal opinion.
To me personally, the problem you describe is a secondary concern, or rather a tertiary / quartenary / quinary / etc. I will keep my effort focused on improving the actual features of JabRef and not a perceived vulnerability. I have taken my fair share of courses in information security and understand the problems. Peoples machines will get compromised not because some malicious attacker investigates the heap of a running JabRef, but because they visit strange websites and download dubious files, or because a download site is hacked and someone attaches malware to otherwise ordinary software. JabRef is simply too insignificant, with too few users, to even consider investing the time in understanding how to hack it. This is not at all a proper solution of course. I would like to have a secure and usable JabRef. But in the light of our very very limited resources and the other features we would like to implement, this is just an ugly practical tradeoff of priorities.
I would gladly support an encryption mechanism if, oh if only there was a library that was not an utter pain in the ass to use. If the security people want software to become more secure, I would appreciate if they invested more time into building usable security (something that is slowly emerging) instead of more clever encryption schemes.
Lastly, the situation can be changed of course: I fully understand if someone considers this a major problem based on his personal preferences and I would be very happy if a person steps forward and implements a nice solution that does not annoy 99% of the remaining users of JabRef. Thus, I encourage you @heseber https://github.com/heseber to implement a proposal and add a pull request. We can then work towards a solution that works for everyone.
Regards
Jörg
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #2249 (comment) , or mute the thread https://github.com/notifications/unsubscribe-auth/AV0qca303XtTecm4BAGNK2dN5p6oTUW4ks5rKlXVgaJpZM4KsPjI .
--
Dr. Henrik Seidel, Grenobler Ring 16, 13127 Berlin
Tel. +49 30 4448650, Mobile +49 1522 8650172
|
|
So in the end, you just don't want to have the password in plain text in the preferences? I can add a very simple encryption/decryption if this is enough for you. But note: regardless of how complicated the encryption is, anybody can, of course, just copy our decryption code and decrypt the password again. So the best we can get from this is "security by obscurity". |
|
Security by obscurity does not really work. I'd suggest to (optionally)
really just ask the user for the password in a popup dialog window if it
was not specified in the preferences and to store it in volatile memory
until the application is closed.
Am 02.01.2017 um 22:08 schrieb Tobias Diez:
…
So in the end, you just don't want to have the password in plain text
in the preferences? I can add a very simple encryption/decryption if
this is enough for you. But note: regardless of how complicated the
encryption is, anybody can, of course, just copy our decryption code
and decrypt the password again. So the best we can get from this is
"security by obscurity".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2249 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AV0qcSyNo37FZXJgjg3JhkapixAV5Z7pks5rOWcygaJpZM4KsPjI>.
--
Dr. Henrik Seidel, Grenobler Ring 16, 13127 Berlin
Tel. +49 30 4448650, Mobile +49 1522 8650172
|
|
Okay, so we would need two options:
Would be fine for me, should be rather straightforward to implement but has not the highest priority as the workaround using the JVM params is already working Edit: I created a feature request post here at discourse: http://discourse.jabref.org/t/prompt-for-proxy-password-on-startup/410 |
Version information
JabRef version JabRef 3.7-dev--snapshot--2016-11-07--master--f07fa32 windows 7 6.1 amd64 Java 1.8.0_112 on Windows 7
Issue description
JabRef is no longer capable of getting through our authenticating firewall. I used to start JabRef like this:
"C:\Program Files\Java\jre1.8.0_112\bin\javaw.exe" -Dhttp.proxyHost="<myproxy>" -Dhttp.proxyPort="8080" -jar "C:\Users\<myname>\AppData\Local\JabRef\JabRef-3.7-dev--snapshot--2016-11-07--master--f07fa32.jar"This still worked with the 2016-10-16 snapshot but now no longer works with the 2016-11-07 snapshot. I also tried to specify proxy/port and user/password in JabRef's settings explicitly, which did not help either.
If possible, it would be great if you made the 2016-10-16 jar file available to me again (which was removed by the update) so that I can check that this older version still works with the proxy and that this issue is is not due to some changes on our side.
Error console - messages caused by starting a medline search
Error console - messages at startup
By the way, I already get quite a number of warnings just after startup before doing anything in the application:
The text was updated successfully, but these errors were encountered: