SUSE-Linux10.1-Beta9-Extra problems
Hey all, First of all, it looks like the non-OSS software repository for opensuse beta9 isn't setup right. ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/ I get this message when I hit finish after adding it as a source (with opensuse 10.1 beta9 x86_64): Curl error for: ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/content. key: Error code: File not found Error message: RETR response: 550 You can still hit skip and use this install source fine. Upon looking at beta9 and previous sources, it looks like the beta9 sources are supposed to have the file content.key containing a PGP key, unlike previous versions, and this key is missing from this repository. This is only an inconvenience for us beta testers, since even if you dont know about using skip, you can download the RPMs themselves. Nevertheless, this should be fixed in the final version for the sake of casual users. Also, nano has been added since beta8. This is GPL and is already included on the media (10.1 x86-64 at least), and thus probably doesn't belong there. I would have posted this to bugzilla, but I figure these are problems with the suse.com repository that can be fixed relatively easily, not a problem with opensuse itself. -Mike
"Michael DePaulo" <msd19@case.edu> writes:
Hey all,
First of all, it looks like the non-OSS software repository for opensuse beta9 isn't setup right.
ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/
It looks more like a bug in YaST, please create a bugreprot against YaST with log files attached,
I get this message when I hit finish after adding it as a source (with opensuse 10.1 beta9 x86_64):
Curl error for: ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/content. key: Error code: File not found Error message: RETR
response: 550
You can still hit skip and use this install source fine.
Upon looking at beta9 and previous sources, it looks like the beta9 sources are supposed to have the file content.key containing a PGP key, unlike previous versions, and this key is missing from this repository.
This is only an inconvenience for us beta testers, since even if you dont know about using skip, you can download the RPMs themselves. Nevertheless, this should be fixed in the final version for the sake of casual users.
Also, nano has been added since beta8. This is GPL and is already included on the media (10.1 x86-64 at least), and thus probably doesn't belong there.
Fixed already in our config.
I would have posted this to bugzilla, but I figure these are problems with the suse.com repository that can be fixed relatively easily, not a problem with opensuse itself.
please report it nevertheless - it's us that has to take some action, we'll try to figure it out ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tue, Apr 04, 2006 at 08:58:12AM +0200, Andreas Jaeger wrote:
"Michael DePaulo" <msd19@case.edu> writes:
Hey all,
First of all, it looks like the non-OSS software repository for opensuse beta9 isn't setup right.
ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/
It looks more like a bug in YaST, please create a bugreprot against YaST with log files attached,
Could this be related to the checking with the content.key? If yes, how is the content.key calculated? On what is it based? (Perhaps people killfiled the makeSUSEdvd thread, so I ask here again) Could we get any info on this security thing, or is is security through obscurity? PS. The reason I ask is because the OP talks about the difference being that there is a content.key in Beta9. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Tue, Apr 04, 2006 at 10:47:46AM +0200, houghi wrote:
On Tue, Apr 04, 2006 at 08:58:12AM +0200, Andreas Jaeger wrote:
"Michael DePaulo" <msd19@case.edu> writes:
Hey all,
First of all, it looks like the non-OSS software repository for opensuse beta9 isn't setup right.
ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/
It looks more like a bug in YaST, please create a bugreprot against YaST with log files attached,
Could this be related to the checking with the content.key? If yes, how is the content.key calculated? On what is it based? (Perhaps people killfiled the makeSUSEdvd thread, so I ask here again)
Could we get any info on this security thing, or is is security through obscurity?
This security thing is very new thats why not much of it is documented yet. - The content.key is a GPG public key, ascii armor protected. - With this key, the content file is signed. The content file contains references to the metadata of CD, including more keys. - YUM repodata also must be signed with one of those public keys to be accepted. In the next beta/rc there will be key dialogs shown that allow accepting, importing keys and similar. Ciao, Marcus
On Tue, Apr 04, 2006 at 01:56:35PM +0200, Marcus Meissner wrote:
This security thing is very new thats why not much of it is documented yet.
OK, I understand that.
- The content.key is a GPG public key, ascii armor protected.
- With this key, the content file is signed. The content file contains references to the metadata of CD, including more keys.
So what would be the best way to work around it? I understand that it won't be a signed DVD ISO anymore, but it can't be, because you can add your own RPMs among other things.
- YUM repodata also must be signed with one of those public keys to be accepted.
I hope there will be a page soon on how to do this.
In the next beta/rc there will be key dialogs shown that allow accepting, importing keys and similar.
Thanks and thanks for the feedback. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Hi, having the (public) signing key on the same media as signed data doesn't add much security, but I'm sure you know. As a poor man's compromise, you could add a md5sum file for every directory, and clear-sign that. That way people could check the MD5 sums the simple way, and if they want to be sure, they can check the signature of the md5sum file(s). I'm using that method for some projects... Regards, Ulrich On 4 Apr 2006 at 13:56, Marcus Meissner wrote:
On Tue, Apr 04, 2006 at 10:47:46AM +0200, houghi wrote:
On Tue, Apr 04, 2006 at 08:58:12AM +0200, Andreas Jaeger wrote:
"Michael DePaulo" <msd19@case.edu> writes:
Hey all,
First of all, it looks like the non-OSS software repository for opensuse beta9 isn't setup right.
ftp://ftp.suse.com/pub/suse/install/10.1/SUSE-Linux10.1-Beta9-Extra/
It looks more like a bug in YaST, please create a bugreprot against YaST with log files attached,
Could this be related to the checking with the content.key? If yes, how is the content.key calculated? On what is it based? (Perhaps people killfiled the makeSUSEdvd thread, so I ask here again)
Could we get any info on this security thing, or is is security through obscurity?
This security thing is very new thats why not much of it is documented yet.
- The content.key is a GPG public key, ascii armor protected.
- With this key, the content file is signed. The content file contains references to the metadata of CD, including more keys.
- YUM repodata also must be signed with one of those public keys to be accepted.
In the next beta/rc there will be key dialogs shown that allow accepting, importing keys and similar.
Ciao, Marcus
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Tue, Apr 04, 2006 at 02:44:25PM +0200, Ulrich Windl wrote:
Hi,
having the (public) signing key on the same media as signed data doesn't add much security, but I'm sure you know. As a poor man's compromise, you could add a md5sum file for every directory, and clear-sign that. That way people could check the MD5 sums the simple way, and if they want to be sure, they can check the signature of the md5sum file(s). I'm using that method for some projects...
Thats why you can get those keys from other sources and cross check from them too. It would have been worse to do no signing at all ;) As for the MD5SUMs, its a good idea too. Ciao, Marcus
participants (5)
-
Andreas Jaeger -
houghi -
Marcus Meissner -
Michael DePaulo -
Ulrich Windl