Hello,
I would like to disable TSL/SSL checks for osc. My SSL configuration is broken and I don't care about security at the moment. I added sslcertck = 0 to ~/.oscrc, but it doesn't help.
cat /etc/issue.net
Welcome to openSUSE 13.1 "Bottle" - Kernel %r (%t).
osc --version
0.152
Of course I can update my osс (build git version), but maybe is there some more simple way to do that?
I use official OBS Applience image http://download.opensuse.org/repositories/OBS:/Server:/2.6/images/iso/obs-se...
Cheers, Alex
On Tue 12 Apr 2016 03:17:41 PM CDT, Alex Naumov wrote:
Hello,
I would like to disable TSL/SSL checks for osc. My SSL configuration is broken and I don't care about security at the moment. I added sslcertck = 0 to ~/.oscrc, but it doesn't help.
cat /etc/issue.net
Welcome to openSUSE 13.1 "Bottle" - Kernel %r (%t).
osc --version
0.152
Of course I can update my osс (build git version), but maybe is there some more simple way to do that?
I use official OBS Applience image http://download.opensuse.org/repositories/OBS:/Server:/2.6/images/iso/obs-se...
Cheers, Alex
Hi AFAIK you need to update python-m2crypto?
Add a --no-verify at the end of your command. Global config in .oscrc: no_verify.
Hi,
Hi
Hi
AFAIK you need to update python-m2crypto?
Add a --no-verify at the end of your command. Global config in .oscrc: no_verify.
Adding no_verify to the .oscrc breaks osc: ConfigParser.ParsingError: File contains parsing errors: /home/name/.oscrc [line 5]: 'no_verify\n'
Adding --no-verify at the end of your command also doesn't help :(
osc ls --no-verify
osc ls: no such option: --no-verify Try 'osc help ls' for info.
I think "--no-verify" works only for "build" command.
Anyway, thanks. Alex
On Tue 12 Apr 2016 05:46:27 PM CDT, Alex Naumov wrote:
Hi,
Hi
Hi
AFAIK you need to update python-m2crypto?
Add a --no-verify at the end of your command. Global config in .oscrc: no_verify.
Adding no_verify to the .oscrc breaks osc: ConfigParser.ParsingError: File contains parsing errors: /home/name/.oscrc [line 5]: 'no_verify\n'
Adding --no-verify at the end of your command also doesn't help :(
osc ls --no-verify
osc ls: no such option: --no-verify Try 'osc help ls' for info.
I think "--no-verify" works only for "build" command.
Anyway, thanks. Alex
Hi sslcertck=0 needs to be in the api section, I use it for packman
osc -Apm ls WARNING: SSL certificate checks disabled. Connection is insecure!
Essentials .... ....
On Tue, Apr 12, 2016 at 6:03 PM, Malcolm malcolmlewis@cableone.net wrote:
Hi sslcertck=0 needs to be in the api section, I use it for packman
osc -Apm ls WARNING: SSL certificate checks disabled. Connection is insecure!
Essentials .... ....
Thank you, Malcolm! I added it to the API section (yes, it should be exactly API section), now it works.
Cheers, Alex
Hi,
why do you do such things?!?!? Even if you don't care about security, others do! You put the whole openSUSE community at risk.
Please stop it!
On 04/12/2016 06:03 PM, Malcolm wrote:
On Tue 12 Apr 2016 05:46:27 PM CDT, Alex Naumov wrote:
Hi,
Hi
Hi
AFAIK you need to update python-m2crypto?
Add a --no-verify at the end of your command. Global config in .oscrc: no_verify.
Adding no_verify to the .oscrc breaks osc: ConfigParser.ParsingError: File contains parsing errors: /home/name/.oscrc [line 5]: 'no_verify\n'
Adding --no-verify at the end of your command also doesn't help :(
osc ls --no-verify
osc ls: no such option: --no-verify Try 'osc help ls' for info.
I think "--no-verify" works only for "build" command.
Anyway, thanks. Alex
Hi sslcertck=0 needs to be in the api section, I use it for packman
osc -Apm ls WARNING: SSL certificate checks disabled. Connection is insecure!
Essentials .... ....
Hello,
On Apr 13 09:55 Thomas Biege wrote (excerpt):
You put the whole openSUSE community at risk.
Do you mean that any openSUSE community member who can configure his "osc" tool on his own local computer can put the whole openSUSE community at risk?
Do you mean that any computer out there where "osc" is used by any openSUSE community member could be e.g. stolen by evil persons and then they could pervert that computer into something evil that could put the whole openSUSE community at risk?
Kind Regards Johannes Meixner
On 04/13/2016 11:05 AM, Johannes Meixner wrote:
Hello,
On Apr 13 09:55 Thomas Biege wrote (excerpt):
You put the whole openSUSE community at risk.
Do you mean that any openSUSE community member who can configure his "osc" tool on his own local computer can put the whole openSUSE community at risk?
Well I assume that at least the credentials and the source code is transferred in plaintext and can be manipulated on the fly or captured. The credentials can be used to impersonate the developer that doesn't use SSL/TLS, which will hurt more than one person.
Thomas Biege thomas@suse.de writes:
Well I assume that at least the credentials and the source code is transferred in plaintext and can be manipulated on the fly or captured.
The API always uses TLS, only certificate verification can be skipped.
Andreas.
On 13/04/16 12:37, Andreas Schwab wrote:
Thomas Biege thomas@suse.de writes:
Well I assume that at least the credentials and the source code is transferred in plaintext and can be manipulated on the fly or captured.
The API always uses TLS, only certificate verification can be skipped.
So it needs an active man in the middle attack or just redirect traffic via DHCP/DNS etc.
Hello,
On Apr 13 12:29 Thomas Biege wrote (excerpt):
On 04/13/2016 11:05 AM, Johannes Meixner wrote:
On Apr 13 09:55 Thomas Biege wrote (excerpt):
You put the whole openSUSE community at risk.
Do you mean that any openSUSE community member who can configure his "osc" tool on his own local computer can put the whole openSUSE community at risk?
Well I assume that at least the credentials and the source code is transferred in plaintext and can be manipulated on the fly or captured.
Of course. But I would assume that anything that was uploaded onto OBS servers is checked before something gets accepted for an openSUSE product regardless how it had been uploaded?
But I would also assume that anything in arbitrary openSUSE community member home projects could be arbitrarily bad.
The credentials can be used to impersonate the developer that doesn't use SSL/TLS, which will hurt more than one person.
Yes. If a well known openSUSE community member is impersonated by another person, that other person could cause some trouble for some time.
But when all what is uploaded under the user account of that openSUSE member is checked before something gets accepted for an openSUSE product, nothing really bad should happen.
For example if someone who seems to be "Thomas Biege" submits a "critical security bugfix" for one of "my" packages in OBS, I would nevertheless have a look if his submission seems to be o.k. for me.
On the other hand I admit that someone where I think he is "Thomas Biege" could fool me with a sufficiently complicated "critical security bugfix" patch but then I would hope that a real openSUSE security team memeber would have another look if that stuff is really o.k.
Kind Regards Johannes Meixner
Hi *,
I can only emphasize: Please, DON'T dilute the security of the opensuse infrastructure, development, community, and product.
Use TLS, verify certs, choose good passwords, change your password from time to time. This will keep opensuse safe and avoids unnecessary bad press due to individuals that behave bad.
Thank you!
On 13/04/16 12:52, Johannes Meixner wrote:
Hello,
On Apr 13 12:29 Thomas Biege wrote (excerpt):
On 04/13/2016 11:05 AM, Johannes Meixner wrote:
On Apr 13 09:55 Thomas Biege wrote (excerpt):
You put the whole openSUSE community at risk.
Do you mean that any openSUSE community member who can configure his "osc" tool on his own local computer can put the whole openSUSE community at risk?
Well I assume that at least the credentials and the source code is transferred in plaintext and can be manipulated on the fly or captured.
Of course. But I would assume that anything that was uploaded onto OBS servers is checked before something gets accepted for an openSUSE product regardless how it had been uploaded?
But I would also assume that anything in arbitrary openSUSE community member home projects could be arbitrarily bad.
The credentials can be used to impersonate the developer that doesn't use SSL/TLS, which will hurt more than one person.
Yes. If a well known openSUSE community member is impersonated by another person, that other person could cause some trouble for some time.
But when all what is uploaded under the user account of that openSUSE member is checked before something gets accepted for an openSUSE product, nothing really bad should happen.
For example if someone who seems to be "Thomas Biege" submits a "critical security bugfix" for one of "my" packages in OBS, I would nevertheless have a look if his submission seems to be o.k. for me.
On the other hand I admit that someone where I think he is "Thomas Biege" could fool me with a sufficiently complicated "critical security bugfix" patch but then I would hope that a real openSUSE security team memeber would have another look if that stuff is really o.k.
Kind Regards Johannes Meixner
-
Alex Naumov -
Andreas Schwab -
Johannes Meixner -
Malcolm -
Thomas Biege