[opensuse-factory] Flash Player dropped from Tumbleweed and Leap 42.1
Hi, As package drops and additions should be mentioned on the -factory list ... Adobe Flash Player has been dropped from both Leap 42.1 and Tumbleweed. If you want to know why you are welcome to give a call to our legal aide Ciaran, whose phone number is in the drop request. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 11:40 AM, Marcus Meissner wrote:
Hi,
As package drops and additions should be mentioned on the -factory list ...
Adobe Flash Player has been dropped from both Leap 42.1 and Tumbleweed.
If you want to know why you are welcome to give a call to our legal aide Ciaran, whose phone number is in the drop request.
Ciao, Marcus
Hi, Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude. Care to explain? Cheers, Mathias -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 26 October 2015 12:19:18 CET Mathias Homann wrote:
Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude.
I guess because the lawyer took the decision to request the deletion ? Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 12:39 PM, Raymond Wooninck wrote:
On Monday, 26 October 2015 12:19:18 CET Mathias Homann wrote:
Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude.
I guess because the lawyer took the decision to request the deletion ?
Regards
Raymond I think Mathias is asking why it's not explained in the maillinglist. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 26, 2015 at 12:40:47PM +0100, Benjamin Denisart wrote:
On 10/26/2015 12:39 PM, Raymond Wooninck wrote:
On Monday, 26 October 2015 12:19:18 CET Mathias Homann wrote:
Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude.
I guess because the lawyer took the decision to request the deletion ?
Regards
Raymond I think Mathias is asking why it's not explained in the maillinglist.
Documenting legal issues in a "written" way can cause a *lot* higher legal damage payments if there would be any, so these things are usually not written down. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude.
I think Mathias is asking why it's not explained in the maillinglist.
Documenting legal issues in a "written" way can cause a *lot* higher legal damage payments if there would be any, so these things are usually not written down.
How does that help when one can just phone the lawyer and then circulate that response to the mailing list? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 12:40 PM, Benjamin Denisart wrote:
On 10/26/2015 12:39 PM, Raymond Wooninck wrote:
On Monday, 26 October 2015 12:19:18 CET Mathias Homann wrote:
Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude.
I guess because the lawyer took the decision to request the deletion ?
Regards
Raymond I think Mathias is asking why it's not explained in the maillinglist.
that. and why there is no link to the request. I've been trying to find the request on OBS and I can£t find it there either. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 12:59 PM, Mathias Homann wrote:
On 10/26/2015 12:39 PM, Raymond Wooninck wrote:
On Monday, 26 October 2015 12:19:18 CET Mathias Homann wrote:
Even though I totally support the decision of getting rid of flash I can't help but feel a bit surprised by this "if you want to know why, ask our lawyer" attitude.
I guess because the lawyer took the decision to request the deletion ?
Regards
Raymond I think Mathias is asking why it's not explained in the maillinglist.
On 10/26/2015 12:40 PM, Benjamin Denisart wrote: that. and why there is no link to the request. I've been trying to find the request on OBS and I can£t find it there either.
https://build.opensuse.org/request/show/339922. And, Marcus tell me if I'm wrong but If I well understand, the request append because of Adobe. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marcus Meissner schrieb:
As package drops and additions should be mentioned on the -factory list ...
Adobe Flash Player has been dropped from both Leap 42.1 and Tumbleweed.
Thanks, this means a lot of people will continue to have the current version installed "until the end of time",even once it becomes horribly insecure. :( KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26 October 2015 at 14:45, Robert Kaiser
Thanks, this means a lot of people will continue to have the current version installed "until the end of time",even once it becomes horribly insecure. :(
Dude, it's flash, it's been horribly insecure since the beginning of time ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.10.2015 um 14:47 schrieb Richard Brown:
On 26 October 2015 at 14:45, Robert Kaiser
wrote: Thanks, this means a lot of people will continue to have the current version installed "until the end of time",even once it becomes horribly insecure. :(
Dude, it's flash, it's been horribly insecure since the beginning of time ;)
ok, but Robert has a point indeed. But then we can discuss based on that concern: Actually Firefox will block outdated Flash versions anyway. So people cannot just continue to use it in many cases. Therefore while there is a point I'm not sure we have to take extra measurements on it. We could think about provided a package to replace earlier flash-player versions shipped by openSUSE which contains "nothing". But then again is it worth the effort? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer [26.10.2015 14:52]:
Am 26.10.2015 um 14:47 schrieb Richard Brown:
On 26 October 2015 at 14:45, Robert Kaiser
wrote: Thanks, this means a lot of people will continue to have the current version installed "until the end of time",even once it becomes horribly insecure. :(
Dude, it's flash, it's been horribly insecure since the beginning of time ;)
ok, but Robert has a point indeed. But then we can discuss based on that concern: Actually Firefox will block outdated Flash versions anyway. So people cannot just continue to use it in many cases. Therefore while there is a point I'm not sure we have to take extra measurements on it.
This "blocking" is just a question. If you decide to continue using the installed Flash version, this is only 1 click away.
We could think about provided a package to replace earlier flash-player versions shipped by openSUSE which contains "nothing". But then again is it worth the effort?
Or you point the folks to the packman Repos, where they will find a package named chromium-pepper-flash, which can be used by Firefox too. Werner --
Richard Brown schrieb:
On 26 October 2015 at 14:45, Robert Kaiser
wrote: Thanks, this means a lot of people will continue to have the current version installed "until the end of time",even once it becomes horribly insecure. :(
Dude, it's flash, it's been horribly insecure since the beginning of time ;)
That may be the case, but a ton of web content unfortunately relies on it. I'd be one of the first people to cheer if Flash would be really obsolete in this world, but even I have to run two things right at this moment (a game and a sports video player) that require Flash. KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-26 15:04, Robert Kaiser wrote:
That may be the case, but a ton of web content unfortunately relies on it. I'd be one of the first people to cheer if Flash would be really obsolete in this world, but even I have to run two things right at this moment (a game and a sports video player) that require Flash.
Same here. Unless I find a way to install Flash, I can't install Leap. Plain as that... I do need Flash, because even my bank uses it, and I have no leverage at all to tell them not to. Or I could use "Chrome" (not chromium) instead of Firefox, at least on those pages; which I do not like because I /guess/ that it tracks more what we do, being a google application. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYuNJEACgkQtTMYHG2NR9V8ugCeM3EMVBPb2+6OpePms0mYxHY2 RsoAn2ENbZtsFImmdadofQTOCcrCTgNc =JfNX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2015-10-26 15:04, Robert Kaiser wrote:
I have to run two things right at this moment (a game and a sports video player) that require Flash.
Nobody has to run, of all things, games. :p And as for sports, perhaps you can throw youtube-dl at it, at least for non-live events. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt schrieb:
On Monday 2015-10-26 15:04, Robert Kaiser wrote:
I have to run two things right at this moment (a game and a sports video player) that require Flash.
Nobody has to run, of all things, games. :p And as for sports, perhaps you can throw youtube-dl at it, at least for non-live events.
The latter will not help for watching live NFL, and that's all I care about. That said, yes, you are right, I don't "have to" play this game or watch live NFL, but unfortunately, if I want to (and I do) I *have to* use Flash for it at this time. :( And that's what I meant. KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 11:26 AM, Robert Kaiser wrote:
Jan Engelhardt schrieb:
On Monday 2015-10-26 15:04, Robert Kaiser wrote:
I have to run two things right at this moment (a game and a sports video player) that require Flash.
Nobody has to run, of all things, games. :p And as for sports, perhaps you can throw youtube-dl at it, at least for non-live events.
The latter will not help for watching live NFL, and that's all I care about.
That said, yes, you are right, I don't "have to" play this game or watch live NFL, but unfortunately, if I want to (and I do) I *have to* use Flash for it at this time. :( And that's what I meant.
KaiRo
Argh damn thunderbird addons... Anyways what I was trying to say: As Marguerite mentioned below, you can use freshplayerplugin if you want to use flash on firefox, its basically a wrapper for the chrome PPAPI pepper flash. If anything its better than using the horribly legacy 11.x.x NPAPI version as pepper flash is up to date in more than security patches (19.x.x). At the moment I can confirm I see it in the openSUSE-Leap-42.1-Oss repo and installing it does make it show up in firefox. -- Regards, Uzair Shamim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Uzair Shamim schrieb:
As Marguerite mentioned below, you can use freshplayerplugin if you want to use flash on firefox, its basically a wrapper for the chrome PPAPI pepper flash. If anything its better than using the horribly legacy 11.x.x NPAPI version as pepper flash is up to date in more than security patches (19.x.x).
It has more featu5res, but not more security patches. 11.2.x for Linux has patches for all known security issues that affect it ported back from the standard release series, at least from what I hear. But yes, you need Flash 19 to get the new feature of Firefox 42 and higher to be shown tabs that produce audio and be able to mute them. Can you confirm that both freshplayerplugin *and* the actual Pepper-Flash it uses are available as packages for Tumbleweed? KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 12:40 PM, Robert Kaiser wrote:
Uzair Shamim schrieb:
As Marguerite mentioned below, you can use freshplayerplugin if you want to use flash on firefox, its basically a wrapper for the chrome PPAPI pepper flash. If anything its better than using the horribly legacy 11.x.x NPAPI version as pepper flash is up to date in more than security patches (19.x.x).
It has more featu5res, but not more security patches. 11.2.x for Linux has patches for all known security issues that affect it ported back from the standard release series, at least from what I hear. But yes, you need Flash 19 to get the new feature of Firefox 42 and higher to be shown tabs that produce audio and be able to mute them.
Can you confirm that both freshplayerplugin *and* the actual Pepper-Flash it uses are available as packages for Tumbleweed?
KaiRo
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972 I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself). WRT packages, at least on Leap, freshplayerplugin is in the OSS repo but you will need some way to get the actual pepper-flash plugin. Seeing as there is no packman repo yet (at least I cannot find it!) you can try using one of the other distro repos but I cannot comment on how "good" that is. Just for the purpose of testing I added the TW repo to see if I could get the plugin to load and it works. However I have removed it now and plan to wait until there is a packman repo for Leap. PS: For TW... freshplayerplugin: https://software.opensuse.org/package/freshplayerplugin chromium-pepper-flash: http://mirror.karneval.cz/pub/linux/packman/suse/openSUSE_Tumbleweed/Essenti... -- Regards, Uzair Shamim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-26 17:58, Uzair Shamim wrote:
Seeing as there is no packman repo yet (at least I cannot find it!)
They hope to have it up this week. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYuXLEACgkQja8UbcUWM1zDVQD/TmkCR4wlB2EHT9CYGQk4/FuR NNZsk/LuKO/qf8G71mkA/2ZTsathDyJ0RMK2MT2/7M/484tOD0LqWOs2/1UUk4o4 =bdwF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26.10.2015 18:58, Uzair Shamim wrote:
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972
I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself).
Flash is not needed for YouTube. They ditched it a while ago. Vahis -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015 01:38 PM, Vahis wrote:
On 26.10.2015 18:58, Uzair Shamim wrote:
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972
I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself).
Flash is not needed for YouTube. They ditched it a while ago.
Vahis
Yes but you can still use it, right click on the player and it will tell you what is being used. For me it showed flash player. -- Regards, Uzair Shamim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26.10.2015 19:44, Uzair Shamim wrote:
On 10/26/2015 01:38 PM, Vahis wrote:
On 26.10.2015 18:58, Uzair Shamim wrote:
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972
I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself).
Flash is not needed for YouTube. They ditched it a while ago.
Vahis
Yes but you can still use it, right click on the player and it will tell you what is being used. For me it showed flash player.
Then that must be a great solution for those who still insist to use flash although it's not needed. Vahis -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Many times sites will still prefer flash even if they have full html5
video support. Try disabling it on some or the sites you use. Many
sites have fallback modes which are more than adequate...if not
better.
--
Jimmy
On Mon, Oct 26, 2015 at 1:43 PM, Vahis
On 26.10.2015 19:44, Uzair Shamim wrote:
On 10/26/2015 01:38 PM, Vahis wrote:
On 26.10.2015 18:58, Uzair Shamim wrote:
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972
I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself).
Flash is not needed for YouTube. They ditched it a while ago.
Vahis
Yes but you can still use it, right click on the player and it will tell you what is being used. For me it showed flash player.
Then that must be a great solution for those who still insist to use flash although it's not needed.
Vahis
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-10-26 at 14:08 -0500, Jimmy Berry wrote:
Try disabling it on some or the sites you use.
I went a step further, after the last round of security vulnerabilities in flash about a month ago, and just removed it. (When flash is disabled, Firefox makes it abundantly clear how many sites are still using this, for exceptionally annoying ads.) I have to say, I don't miss it. Yes, there have been a few sites where content didn't play, but nothing I *needed*. With iOS devices having never supported flash, and Android devices joining that group years ago, the *need* for flash has dwindled, and only us desktop users must suffer it. If I did hit something I needed, well, there's always Chrome. ;-) -- James Mason Technical Architect, Public Cloud openSUSE Member SUSE jmason@suse.com ------------------------------------- SUSECon 2015: Register at susecon.com
On 10/26/2015 02:43 PM, Vahis wrote:
On 26.10.2015 19:44, Uzair Shamim wrote:
On 10/26/2015 01:38 PM, Vahis wrote:
Flash is not needed for YouTube. They ditched it a while ago.
Vahis
Yes but you can still use it, right click on the player and it will tell you what is being used. For me it showed flash player.
Then that must be a great solution for those who still insist to use flash although it's not needed.
Vahis
I was just providing an example for Robert to show that it works :) Personally I don't even use flash unless I absolutely need it for something important. And when I do use it, its always inside of a virtual machine. -- Regards, Uzair Shamim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-26 19:43, Vahis wrote:
Then that must be a great solution for those who still insist to use flash although it's not needed.
Well, TV sites in Spain use Flash, last time I looked. My cable ISP requires Silverlight. Since recently, it works in Chrome (Linux) with an experimental plugin, called "native client module". It is not that I want to use Flash, it is that some sites I use force me to use Flash. No choice. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYup2oACgkQja8UbcUWM1zJ8gEAhtnNkrbvILKJMcwYzA5UrCm+ M4sOAxmmFM9ha3w6NzAA/jTEvjnJJ1nMzOzCrHioWdwnMg0SulLPu+OIFLqWOJP2 =cO1T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op maandag 26 oktober 2015 23:21:30 schreef Carlos E. R.:
On 2015-10-26 19:43, Vahis wrote:
Then that must be a great solution for those who still insist to use flash although it's not needed.
Well, TV sites in Spain use Flash, last time I looked.
My cable ISP requires Silverlight. Since recently, it works in Chrome (Linux) with an experimental plugin, called "native client module".
Then it's no longer Silverlight. Google blocks Silverlight in Chrome for it's security, or rather the lack of security. Firefox and Pipelight can do Silverlight based sites fine.
It is not that I want to use Flash, it is that some sites I use force me to use Flash. No choice.
The pipelight-plugin does Silverlight AND Flash
-- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith))
-- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-27 09:13, Knurpht - Gertjan Lettink wrote:
Op maandag 26 oktober 2015 23:21:30 schreef Carlos E. R.:
It is not that I want to use Flash, it is that some sites I use force me to use Flash. No choice.
The pipelight-plugin does Silverlight AND Flash
Try this one: http://www.atresplayer.com/directos/television/lasexta/ I just tried, on Leap, and it is using Flash (on FF), which has not been removed yet by updates (yet?). I'm running now another zypper dup (a thousand changes) and I'll try again. [...] Yes, it warns that it is outdated, but runs. The page offers to update the plugin. Trying. It takes me to https://www.mozilla.org/en-US/plugincheck/?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=plugincheck-update Adobe Flash Player vulnerable Shockwave Flash 11.2 r202 11.2.202.508 Clicking on update takes to: https://get.adobe.com/flashplayer/ I have to select the appropriate version (rpm for Linux), and click download. Firefox proposes to "install/remove software (default). YaST starts, after giving root's password. I get a conflict. Related? #### YaST2 conflicts list - generated 2015-10-27 16:45:28 #### nothing provides appdata(thunderbird.appdata.xml) needed by application:Thunderbird-.noarch [ ] deinstallation of application:Thunderbird-.noarch [ ] break application:Thunderbird-.noarch by ignoring some of its dependencies nothing provides appdata(Thunar.appdata.xml) needed by application:Thunar File Manager-.noarch [ ] deinstallation of application:Thunar File Manager-.noarch [ ] break application:Thunar File Manager-.noarch by ignoring some of its dependencies #### YaST2 conflicts list END ### I choose "break". YaST proceeds with installation... There is a problem, the old version was not removed automatically: Eleanor-421:~ # rpm -qa | grep -i flash flash-plugin-11.2.202.540-release.x86_64 flash-player-gnome-11.2.202.508-1.2.x86_64 flash-player-11.2.202.508-1.2.x86_64 Eleanor-421:~ # Eleanor-421:~ # rpm --erase flash-player flash-player-gnome Eleanor-421:~ # Refreshing Firefox plugin page now lists no flash. Maybe needs a restart. [...]. No, there is no flash plugin, something else must be needed. Probably a link. And the media pages like http://www.atresplayer.com/directos/television/lasexta/ now fail. It proposes me to install Flash. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Op dinsdag 27 oktober 2015 15:59:31 schreef Carlos E. R.:
On 2015-10-27 09:13, Knurpht - Gertjan Lettink wrote:
Op maandag 26 oktober 2015 23:21:30 schreef Carlos E. R.:
It is not that I want to use Flash, it is that some sites I use force me to use Flash. No choice.
The pipelight-plugin does Silverlight AND Flash
Try this one:
http://www.atresplayer.com/directos/television/lasexta/
I just tried, on Leap, and it is using Flash (on FF), which has not been removed yet by updates (yet?). I'm running now another zypper dup (a thousand changes) and I'll try again.
[...]
Yes, it warns that it is outdated, but runs.
The page offers to update the plugin. Trying. It takes me to <https://www.mozilla.org/en-US/plugincheck/?utm_source=firefox-browser&utm_m edium=firefox-browser&utm_campaign=plugincheck-update>
Adobe Flash Player vulnerable Shockwave Flash 11.2 r202 11.2.202.508
Clicking on update takes to: https://get.adobe.com/flashplayer/
I have to select the appropriate version (rpm for Linux), and click download. Firefox proposes to "install/remove software (default).
YaST starts, after giving root's password.
I get a conflict. Related?
#### YaST2 conflicts list - generated 2015-10-27 16:45:28 ####
nothing provides appdata(thunderbird.appdata.xml) needed by application:Thunderbird-.noarch
[ ] deinstallation of application:Thunderbird-.noarch
[ ] break application:Thunderbird-.noarch by ignoring some of its dependencies
nothing provides appdata(Thunar.appdata.xml) needed by application:Thunar File Manager-.noarch
[ ] deinstallation of application:Thunar File Manager-.noarch
[ ] break application:Thunar File Manager-.noarch by ignoring some of its dependencies
#### YaST2 conflicts list END ###
I choose "break". YaST proceeds with installation...
There is a problem, the old version was not removed automatically:
Eleanor-421:~ # rpm -qa | grep -i flash flash-plugin-11.2.202.540-release.x86_64 flash-player-gnome-11.2.202.508-1.2.x86_64 flash-player-11.2.202.508-1.2.x86_64 Eleanor-421:~ # Eleanor-421:~ # rpm --erase flash-player flash-player-gnome Eleanor-421:~ #
Refreshing Firefox plugin page now lists no flash. Maybe needs a restart. [...]. No, there is no flash plugin, something else must be needed. Probably a link.
And the media pages like http://www.atresplayer.com/directos/television/lasexta/ now fail. It proposes me to install Flash.
In ancient times we used to download the tar.gz, unpack it and copy libflashplayer.so to /usr/lib/browser-plugins or ~/.mozilla/plugins. Doesn't that work any more? -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-27 16:25, Knurpht - Gertjan Lettink wrote:
In ancient times we used to download the tar.gz, unpack it and copy libflashplayer.so to /usr/lib/browser-plugins or ~/.mozilla/plugins. Doesn't that work any more?
Yes, but I had to locate what to link where :-) Eleanor-421:~ # ln -s /usr/lib64/flash-plugin/libflashplayer.so /usr/lib64/browser-plugins/libflashplayer.so Eleanor-421:~ # and now Flash works in Leap :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-28 03:31, Carlos E. R. wrote:
and now Flash works in Leap :-)
Found new problem: "zypper dup" wants to reinstall the old flash plugins: Detected 2 file conflicts: File /usr/bin/flash-player-properties from install of flash-player-gnome-11.2.202.508-1.2.x86_64 (openSUSE-Leap-Non-Oss) conflicts with file from package flash-plugin-11.2.202.540-release.x86_64 (@System) File /usr/share/applications/flash-player-properties.desktop from install of flash-player-gnome-11.2.202.508-1.2.x86_64 (openSUSE-Leap-Non-Oss) conflicts with file from package flash-plugin-11.2.202.540-release.x86_64 (@System) File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content. Continue? [yes/no] (no): I suppose I have to say no now, and later taboo "flash-player-gnome". The correct solution should be to actually remove it from the repositories. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYwR/wACgkQtTMYHG2NR9VFfQCfb+6Lvv6NmMBXvm8Z7GHmRE0v yPcAmwT3XT0yTjH9Fev/wmQpk3ZvEqt0 =vu5e -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Carlos E. R."
The correct solution should be to actually remove it from the repositories.
That will happen automatically when it is published the next time. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-10-27 at 15:59 +0100, Carlos E. R. wrote:
I get a conflict. Related?
The two conflicts seem not to be related at all. which is good
#### YaST2 conflicts list - generated 2015-10-27 16:45:28 ####
nothing provides appdata(thunderbird.appdata.xml) needed by application:Thunderbird-.noarch
[ ] deinstallation of application:Thunderbird-.noarch
[ ] break application:Thunderbird-.noarch by ignoring some of its dependencies
Wolfgang just fixed that one in MozillaFirefox; I guess the packages are similar enough that it warrants a fix in Thunderbird too; please file a bug directly.
nothing provides appdata(Thunar.appdata.xml) needed by application:Thunar File Manager-.noarch
[ ] deinstallation of application:Thunar File Manager-.noarch
[ ] break application:Thunar File Manager-.noarch by ignoring some of its dependencies
That one can be seen as a libzypp bug or a thunar bug; the fix is certainly easier in Thunar. The package provides: appdata(thunar.appdata.xml) and application(Thunar.desktop) Now, thunar does not really do anything 'invalid' there, as the provided appdata.xml correctly references Thunar.desktop, but libzypp falls on the nose with it. For this error to disappear, the appdata file and the .desktop file should use the same basename. So the easiest fix is for Thunar to rename thunar.appdata.xml to Thunar.appdata.xml; then the problem disappears (do not rename the .desktop file, or you will need to patch the appdata.xml, which references the .desktop file by name) In the longer run, libzypp might need a fix to not be so pedantic about it (the AppData standard does not mandate the names to be equal; but from any upstream project PoV, it's good practice to reuse the naming schemes throughout the project anyway). So, you see: best to file a bug against Thunar here Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-27 16:38, Dominique Leuenberger / DimStar wrote:
On Tue, 2015-10-27 at 15:59 +0100, Carlos E. R. wrote:
Wolfgang just fixed that one in MozillaFirefox; I guess the packages are similar enough that it warrants a fix in Thunderbird too; please file a bug directly.
Done: https://bugzilla.opensuse.org/show_bug.cgi?id=952325 ...
So, you see: best to file a bug against Thunar here
Done: https://bugzilla.opensuse.org/show_bug.cgi?id=952324 - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYwLkoACgkQtTMYHG2NR9U1pQCeLreKi/2tDfcadvSI9bGYzstu nZEAoI0o6f+F4JqpKSHQ34RftRVSCSXL =Ar0D -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/26/2015, 06:38 PM, Vahis wrote:
On 26.10.2015 18:58, Uzair Shamim wrote:
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972
I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself).
Flash is not needed for YouTube. They ditched it a while ago.
That's not true at all. Many videos cannot be played only using html5 on youtube. See https://www.youtube.com/html5 thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jiri Slaby
On 10/26/2015, 06:38 PM, Vahis wrote:
On 26.10.2015 18:58, Uzair Shamim wrote:
According to Adobe, freshplayerplugin/pepper-flash is at the latest version: http://paste.opensuse.org/view/raw/a8461972
I have tested it on *Leap* and I can play youtube videos fine. If there is a particular site you are concerned about I can test it if you provide a link (or you can just install the plugin and try it yourself).
Flash is not needed for YouTube. They ditched it a while ago.
That's not true at all. Many videos cannot be played only using html5 on youtube. See https://www.youtube.com/html5
But all videos can be played via youtube-dl. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/27/2015, 11:33 AM, Andreas Schwab wrote:
But all videos can be played via youtube-dl.
Useless: are you going to educate every random user? -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jiri Slaby
On 10/27/2015, 11:33 AM, Andreas Schwab wrote:
But all videos can be played via youtube-dl.
Useless: are you going to educate every random user?
Worksforme, that's all I care. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Please excuse me, but that is not the right attitude to spread openSUSE. That works not for me, not for my wife, not for my children, not for my sister, ... Stefan Zimmer Am Dienstag, 27. Oktober 2015, 11:50:24 schrieb Andreas Schwab:
Jiri Slaby
writes: On 10/27/2015, 11:33 AM, Andreas Schwab wrote:
But all videos can be played via youtube-dl.
Useless: are you going to educate every random user?
Worksforme, that's all I care.
Andreas.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
ti., 27.10.2015 kl. 11.26 +0100, skrev Jiri Slaby:
On 10/26/2015, 06:38 PM, Vahis wrote:
Flash is not needed for YouTube. They ditched it a while ago.
That's not true at all. Many videos cannot be played only using html5 on youtube. See https://www.youtube.com/html5
thanks, -- js suse labs
I've been using html5 only on youtube for ages, and I've yet to come across a video I can't play without flash, but I might have been lucky. Could someone please send a link for such a video on youtube.com? Because I suspect that this was true in the past, but not anymore. That there might be a lot of other videosites that have not migrated everything to html5 is an other matter. //Bjørn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, well, it's not youtube, but what about golem.de or spiegel.de? Both very popular news sites in germany. Greetings, stefan Am Dienstag, 27. Oktober 2015, 12:15:57 schrieb Bjørn Lie:
ti., 27.10.2015 kl. 11.26 +0100, skrev Jiri Slaby:
On 10/26/2015, 06:38 PM, Vahis wrote:
Flash is not needed for YouTube. They ditched it a while ago.
That's not true at all. Many videos cannot be played only using html5 on youtube. See https://www.youtube.com/html5
thanks,
I've been using html5 only on youtube for ages, and I've yet to come across a video I can't play without flash, but I might have been lucky.
Could someone please send a link for such a video on youtube.com? Because I suspect that this was true in the past, but not anymore.
That there might be a lot of other videosites that have not migrated everything to html5 is an other matter.
//Bjørn
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, well, it's not youtube, but what about other sites, for example golem.de or spiegel.de? Both very popular news sites in germany. Greetings, Stefan Am Dienstag, 27. Oktober 2015, 12:15:57 schrieb Bjørn Lie:
ti., 27.10.2015 kl. 11.26 +0100, skrev Jiri Slaby:
On 10/26/2015, 06:38 PM, Vahis wrote:
Flash is not needed for YouTube. They ditched it a while ago.
That's not true at all. Many videos cannot be played only using html5 on youtube. See https://www.youtube.com/html5
thanks,
I've been using html5 only on youtube for ages, and I've yet to come across a video I can't play without flash, but I might have been lucky.
Could someone please send a link for such a video on youtube.com? Because I suspect that this was true in the past, but not anymore.
That there might be a lot of other videosites that have not migrated everything to html5 is an other matter.
//Bjørn
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27.10.2015 12:24, Stefan Zimmer wrote:
Hi,
well, it's not youtube, but what about other sites, for example golem.de or spiegel.de? Both very popular news sites in germany.
You can still download flash-player from adobe's web site - and that's what adobe wants you to do Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-27 12:32, Stephan Kulow wrote:
You can still download flash-player from adobe's web site - and that's what adobe wants you to do
Why was this not said in the initial post? ;-) Would have saved noise. It is about the same we do with the JRE, no? The question then arises, how to learn when to do updates, and how to do them. Maybe someone can find out and post on the wiki :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2015-10-27 14:47, Carlos E. R. wrote: The link is: http://get.adobe.com/flashplayer/otherversions/ this got me: https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.540/flash-plugin-1... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hello, On Oct 27 14:56 Carlos E. R. wrote (excerpt):
The link is:
Right now I created https://en.opensuse.org/Adobe_Flash_Player as a starting point - just as I did it for https://en.opensuse.org/Adobe_Reader I would very much appreciate it if https://en.opensuse.org/Adobe_Flash_Player is enhanced and extended by those who better than I know how to deal with that issue so that the issue is sufficiently well explained to unexperienced openSUSE users so that they can understand what the issue is and how to deal with it. Many thanks in advance for all valuable contribution! Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-27 16:16, Johannes Meixner wrote:
https://en.opensuse.org/Adobe_Flash_Player
is enhanced and extended by those who better than I know how to deal with that issue so that the issue is sufficiently well explained to unexperienced openSUSE users so that they can understand what the issue is and how to deal with it.
Done :-) Others more accustomed to writing wiki pages can now polish it. After all, English is not my first language ;-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYwRwgACgkQtTMYHG2NR9U7LQCeN0iIfZcgYeUthkHVrysvLYAT TJAAnij6/w6k2yp6CTMD46exNylJ7due =TTfw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-28 04:54, Carlos E. R. wrote:
On 2015-10-27 16:16, Johannes Meixner wrote:
Done :-)
Others more accustomed to writing wiki pages can now polish it. After all, English is not my first language ;-)
I see you have been working on it. I like very much your changes, thanks :-) Some one has to add a section for adding YUM repo, it seems very promising, but I haven't tested it. Updates would happen automatically with "zypper up". - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYwsUcACgkQtTMYHG2NR9XYSACgiZD5+9dhizTAblUpjfAE3Tpu Mw8Amwa29ulqp03vueW6lT95wxspfMT5 =vfT4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 October 2015 16:16:29 Johannes Meixner wrote:
[…] Right now I created
https://en.opensuse.org/Adobe_Flash_Player
as a starting point - just as I did it for
https://en.opensuse.org/Adobe_Reader
I would very much appreciate it if
https://en.opensuse.org/Adobe_Flash_Player
is enhanced and extended by those who better than I know how to deal with that issue so that the issue is sufficiently well explained to unexperienced openSUSE users so that they can understand what the issue is and how to deal with it.
Many thanks in advance for all valuable contribution!
I would recommend that someone with more insight into what is "The Right Solution" would update the wiki page https://en.opensuse.org/Adobe_Flash_Player Right now it still states the "manual download" approach as the first and therefore "preferred" solution which I think is inferior, more tedious and also less secure for non-experts to do right. Could someone provide instructions how to install from an existing repository be it as part of the community repositories/packman/something_else? Regards, Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-02 07:46, Oliver Kurz wrote:
Right now it still states the "manual download" approach as the first and therefore "preferred" solution which I think is inferior, more tedious and also less secure for non-experts to do right.
It was the only method known at the time or writing it ;-)
Could someone provide instructions how to install from an existing repository be it as part of the community repositories/packman/something_else?
Frederic Crozat did just that :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10/27/2015 02:47 PM, Carlos E. R. wrote:
On 2015-10-27 12:32, Stephan Kulow wrote:
You can still download flash-player from adobe's web site - and that's what adobe wants you to do Why was this not said in the initial post? ;-) Would have saved noise. It is about the same we do with the JRE, no?
The question then arises, how to learn when to do updates, and how to do them. Maybe someone can find out and post on the wiki :-?
Adobe provides a yum repository, I'd assume that is the way to go for updates now. Haven't tested it on anything other than RHEV so far tho. Cheers Mathias -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 27, 2015 at 11:40 AM, Mathias Homann
On 10/27/2015 02:47 PM, Carlos E. R. wrote:
On 2015-10-27 12:32, Stephan Kulow wrote:
You can still download flash-player from adobe's web site - and that's what adobe wants you to do Why was this not said in the initial post? ;-) Would have saved noise. It is about the same we do with the JRE, no?
The question then arises, how to learn when to do updates, and how to do them. Maybe someone can find out and post on the wiki :-?
Adobe provides a yum repository, I'd assume that is the way to go for updates now. Haven't tested it on anything other than RHEV so far tho.
I've been using adobe's yum repository for a while now. It used to require lsb, not sure if it's still the case (which is no problem on TW or Leap AFAIK, but thought I'd mention). It works fine, but at one point I needed to add a symlink to firefox for it to find the plugin. It was a long while ago. So, summary, it's not as smooth a ride as openSUSE's package, but it works well enough. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-27 16:43, Claudio Freire wrote:
On Tue, Oct 27, 2015 at 11:40 AM, Mathias Homann
Adobe provides a yum repository, I'd assume that is the way to go for updates now. Haven't tested it on anything other than RHEV so far tho.
I've been using adobe's yum repository for a while now.
Why YUM? There are rpms. :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Отправлено с iPhone
28 окт. 2015 г., в 7:01, Carlos E. R.
написал(а): On 2015-10-27 16:43, Claudio Freire wrote: On Tue, Oct 27, 2015 at 11:40 AM, Mathias Homann
Adobe provides a yum repository, I'd assume that is the way to go for updates now. Haven't tested it on anything other than RHEV so far tho.
I've been using adobe's yum repository for a while now.
Why YUM? There are rpms. :-?
YUM is based on RPM. I won't be surprised if YaST supports them.-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 28, 2015 at 2:24 AM, Andrei Borzenkov
28 окт. 2015 г., в 7:01, Carlos E. R.
написал(а): On 2015-10-27 16:43, Claudio Freire wrote: On Tue, Oct 27, 2015 at 11:40 AM, Mathias Homann
Adobe provides a yum repository, I'd assume that is the way to go for updates now. Haven't tested it on anything other than RHEV so far tho.
I've been using adobe's yum repository for a while now.
Why YUM? There are rpms. :-?
YUM is based on RPM. I won't be surprised if YaST supports them.--
It's just a repo format, and yes, zypper does support it. As to why, well, a repo is far easier to deal with than a plain rpm. For one, the repo gets you updates as soon as they come out. I think apper even notifies you that you've got an update -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-28 07:02, Claudio Freire wrote:
As to why, well, a repo is far easier to deal with than a plain rpm. For one, the repo gets you updates as soon as they come out. I think apper even notifies you that you've got an update
Ah, you mean a repo. Then you need to tell the URL that has to be added, and the procedure, then write it up in the wiki page as another procedure ;-) I just tried YUM in the adobe page, and what is does is download an rpm from http://linuxdownload.adobe.com/adobe-release/adobe-release-x86_64-1.0-1.noar..., sized 4.2 KB, which would install: - -rw-r--r-- 1 root root 1726 Mar 8 2011 /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux - -rw-r--r-- 1 root root 183 Apr 1 2011 /etc/yum.repos.d/adobe-linux-x86_64.repo The second file contains: [adobe-linux-x86_64] name=Adobe Systems Incorporated baseurl=http://linuxdownload.adobe.com/linux/x86_64/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux That link gives "forbidden". I don't know if it would work with zypper or not, I haven't checked that far. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYwodQACgkQtTMYHG2NR9W1NwCfcI2vIidYFaS+YyJSstoOZfTw hjIAniJkheYTDVD12o7XP3nlP51NnTGD =X/eJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 28, 2015 at 12:22 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The second file contains:
[adobe-linux-x86_64] name=Adobe Systems Incorporated baseurl=http://linuxdownload.adobe.com/linux/x86_64/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
Based on that file: robert@rombert:~> sudo zypper ar http://linuxdownload.adobe.com/linux/x86_64/ adobe Adding repository 'adobe' .....................................................................................................[done] Repository 'adobe' successfully added Enabled : Yes Autorefresh : No GPG Check : Yes URI : http://linuxdownload.adobe.com/linux/x86_64/ robert@rombert:~> sudo zypper ref adobe Retrieving repository 'adobe' metadata ........................................................................................[done] Building repository 'adobe' cache .............................................................................................[done] Specified repositories have been refreshed. robert@rombert:~> sudo zypper se -r adobe Loading repository data... Reading installed packages... S | Name | Summary | Type --+----------------------+------------------------------------------+-------- | adobe-release-x86_64 | linux.adobe.com Repository Configuration | package | flash-plugin | Adobe Flash Player 11.2 | package So it should work. Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Onsdag den 28. oktober 2015 12:28:33 skrev Robert Munteanu:
robert@rombert:~> sudo zypper ar http://linuxdownload.adobe.com/linux/x86_64/ adobe
I guess it might make sense for me to add this repo to the YaST Community repositories lists (opensuse-community.org section). To make it easy to add it with clicky, clicky. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-28 21:48, Martin Schlander wrote:
I guess it might make sense for me to add this repo to the YaST Community repositories lists (opensuse-community.org section). To make it easy to add it with clicky, clicky.
If it works, that would be fantastic :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Onsdag den 28. oktober 2015 21:48:03 skrev Martin Schlander:
Onsdag den 28. oktober 2015 12:28:33 skrev Robert Munteanu:
robert@rombert:~> sudo zypper ar http://linuxdownload.adobe.com/linux/x86_64/ adobe
I guess it might make sense for me to add this repo to the YaST Community repositories lists (opensuse-community.org section). To make it easy to add it with clicky, clicky.
I added the repo to the list, but removed it again a few minutes later, as I realized Packman have started providing flash-player. I think it's cleaner this way. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1 November 2015 at 12:08, Martin Schlander
Onsdag den 28. oktober 2015 21:48:03 skrev Martin Schlander:
Onsdag den 28. oktober 2015 12:28:33 skrev Robert Munteanu:
robert@rombert:~> sudo zypper ar http://linuxdownload.adobe.com/linux/x86_64/ adobe
I guess it might make sense for me to add this repo to the YaST Community repositories lists (opensuse-community.org section). To make it easy to add it with clicky, clicky.
I added the repo to the list, but removed it again a few minutes later, as I realized Packman have started providing flash-player.
I think it's cleaner this way.
Martin, I have a suggestion - why not add the various sub-projects of Packman to the list, so people can still easily add Packman without all the extra (and sometimes) messy bonus stuff that comes with 'full packman'? The names are pretty much self explanatory Packman Essentials http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Essentials <- All you need for codecs Packman Extra http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Extra <- this is the one which now includes Flash Packman Games http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Games Packman Multimedia http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Multimedia <- additional multimedia applications I personally only ever use Packman Essentials - would be nice to be able to access it via the Community Repo list instead of doing it manually ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sonntag, 1. November 2015, 12:48:35 schrieb Richard Brown:
On 1 November 2015 at 12:08, Martin Schlander
wrote: Onsdag den 28. oktober 2015 21:48:03 skrev Martin Schlander:
Onsdag den 28. oktober 2015 12:28:33 skrev Robert Munteanu:
robert@rombert:~> sudo zypper ar http://linuxdownload.adobe.com/linux/x86_64/ adobe
I guess it might make sense for me to add this repo to the YaST Community repositories lists (opensuse-community.org section). To make it easy to add it with clicky, clicky.
I added the repo to the list, but removed it again a few minutes later, as I realized Packman have started providing flash-player.
I think it's cleaner this way.
Martin, I have a suggestion - why not add the various sub-projects of Packman to the list, so people can still easily add Packman without all the extra (and sometimes) messy bonus stuff that comes with 'full packman'?
The names are pretty much self explanatory
Packman Essentials http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Essentials <- All you need for codecs Packman Extra http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Extra <- this is the one which now includes Flash Packman Games http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Games Packman Multimedia http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_42.1/Multimedia <- additional multimedia applications
I personally only ever use Packman Essentials - would be nice to be able to access it via the Community Repo list instead of doing it manually ;)
The one who knews the sub-repos of packman is able to set it manually. The one who "needs" packman and "needs" clicky clicky is safer with the whole repo i think -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.11.15 schrieb Daniel Fuhrmann:
The one who knews the sub-repos of packman is able to set it manually. The one who "needs" packman and "needs" clicky clicky is safer with the whole repo i think
- -1 I would vote for providing the sub-repos. Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlY2fX8ACgkQzi3gQ/xETbI7tgCfSvX+iGtzlTsNzzILcGSxtUC7 cwkAniniJsxXULu24LCAd8B9IKGzs7tA =8UbY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-01 22:00, Johannes Kastl wrote:
Am 01.11.15 schrieb Daniel Fuhrmann:
The one who knews the sub-repos of packman is able to set it manually. The one who "needs" packman and "needs" clicky clicky is safer with the whole repo i think
-1
I would vote for providing the sub-repos.
I have seen people having packman defined several times. If the subrepos are provided that easy, people will have all of them defined, plus the complete one. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Søndag den 1. november 2015 22:09:13 skrev Carlos E. R.:
On 2015-11-01 22:00, Johannes Kastl wrote:
Am 01.11.15 schrieb Daniel Fuhrmann:
The one who knews the sub-repos of packman is able to set it manually. The one who "needs" packman and "needs" clicky clicky is safer with the whole repo i think
-1
I would vote for providing the sub-repos.
I have seen people having packman defined several times. If the subrepos are provided that easy, people will have all of them defined, plus the complete one.
Yeah, the "better add one too many, than one too few" approach. I also lean towards having all of them there would be too "confusing for users" and bloat up the repo list. But maybe just adding "Essentials" as a lighter alternative, might be worth considering. Doesn't seem that flash-player is in essentials though :-| -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 02 novembre 2015 à 09:59 +0100, Martin Schlander a écrit :
Søndag den 1. november 2015 22:09:13 skrev Carlos E. R.:
On 2015-11-01 22:00, Johannes Kastl wrote:
Am 01.11.15 schrieb Daniel Fuhrmann:
The one who knews the sub-repos of packman is able to set it manually. The one who "needs" packman and "needs" clicky clicky is safer with the whole repo i think
-1
I would vote for providing the sub-repos.
I have seen people having packman defined several times. If the subrepos are provided that easy, people will have all of them defined, plus the complete one.
Yeah, the "better add one too many, than one too few" approach.
I also lean towards having all of them there would be too "confusing for users" and bloat up the repo list. But maybe just adding "Essentials" as a lighter alternative, might be worth considering.
Doesn't seem that flash-player is in essentials though :-
I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on openSUSE and is even providing a yum repository which is working nicely with zypper. The simplest way is to direct users to do: zypper ar --check --refresh http://linuxdownload.adobe.com/linux/x86_64/ adobe then zypper in flash-plugin and that's it. This way, we know the flash plugin will ALWAYS be up to date, until Adobe decided to kill it in the future. I've taken the liberty to edit the wiki page to add this option as the first option (and removed the "local repository" option, since there is no point in documenting this). -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 02 novembre 2015 à 10:32 +0100, Frederic Crozat a écrit :
Le lundi 02 novembre 2015 à 09:59 +0100, Martin Schlander a écrit :
Søndag den 1. november 2015 22:09:13 skrev Carlos E. R.:
On 2015-11-01 22:00, Johannes Kastl wrote:
Am 01.11.15 schrieb Daniel Fuhrmann:
The one who knews the sub-repos of packman is able to set it manually. The one who "needs" packman and "needs" clicky clicky is safer with the whole repo i think
-1
I would vote for providing the sub-repos.
I have seen people having packman defined several times. If the subrepos are provided that easy, people will have all of them defined, plus the complete one.
Yeah, the "better add one too many, than one too few" approach.
I also lean towards having all of them there would be too "confusing for users" and bloat up the repo list. But maybe just adding "Essentials" as a lighter alternative, might be worth considering.
Doesn't seem that flash-player is in essentials though :-
I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on openSUSE and is even providing a yum repository which is working nicely with zypper.
The simplest way is to direct users to do: zypper ar --check --refresh http://linuxdownload.adobe.com/linux/x86_64/ adobe
then zypper in flash-plugin
and that's it. This way, we know the flash plugin will ALWAYS be up to date, until Adobe decided to kill it in the future.
I've taken the liberty to edit the wiki page to add this option as the first option (and removed the "local repository" option, since there is no point in documenting this).
I also took the liberty to contact maintainers of Community repository list to get this repository added -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 2, 2015 at 12:32 PM, Frederic Crozat
I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on
As far as I understood this RPM still requires manual link for browser plugin, at least that is what Carlos wrote. Looking at RPMs Adobe install browser into /usr/lib64/flash-plugin/libflashplayer.so openSUSE RPM installs it into install -Dm 0644 libflashplayer.so %{buildroot}%{_libdir}/browser-plugins/libflashplayer.so there are also some cosmetic improvements in openSUSE RPM regarding DE integration. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andrei Borzenkov composed on 2015-11-02 12:51 (UTC+0300):
Frederic Crozat wrote:
I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on
As far as I understood this RPM still requires manual link for browser plugin, at least that is what Carlos wrote.
Assuming I'm understanding what this means, the Adobe installation method offers the advantage that those who have multiple browsers installed aren't forced to have Flash available in every browser. This machine purposely has Flash accessible to only one out of about ten different installed browsers and several times that many user profiles. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Mandag den 2. november 2015 12:51:40 skrev Andrei Borzenkov:
On Mon, Nov 2, 2015 at 12:32 PM, Frederic Crozat
wrote: I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on
As far as I understood this RPM still requires manual link for browser plugin, at least that is what Carlos wrote. Looking at RPMs
I tested the Adobe repo/package on Leap and it worked in Firefox at least without any need to create symlinks or such. However it doesn't import the gpg key, so users will need to do that manually, or ignore the warning. As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash-player' from Packman. But there are valid arguments both ways. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer. And honoring the work done by Adobe by promoting their own repo is not wrong neither. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Mandag den 2. november 2015 11:55:23 skrev Dominique Leuenberger / DimStar:
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer.
And honoring the work done by Adobe by promoting their own repo is not wrong neither.
Ok. I added the repo to the yast community repos list for Leap 42.1 and Tumbleweed. We'll see what happens. The Packman 64-bit package is broken currently anyway (wants to install a whole bunch of 32-bit libs). For Tumbleweed I had to add two separate repos of course. But I have tried to make it clear in the text which repo to use for which arch. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 02.11.2015 um 11:55 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer.
And honoring the work done by Adobe by promoting their own repo is not wrong neither.
Keep in mind that whoever's repo you add gets root access to your system. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 3, 2015 at 4:06 AM, Ludwig Nussel
Am 02.11.2015 um 11:55 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer.
And honoring the work done by Adobe by promoting their own repo is not wrong neither.
Keep in mind that whoever's repo you add gets root access to your system.
And that's different from the flash pullin package... how? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 03, 2015 at 10:53:57AM -0300, Claudio Freire wrote:
On Tue, Nov 3, 2015 at 4:06 AM, Ludwig Nussel
wrote: Am 02.11.2015 um 11:55 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer.
And honoring the work done by Adobe by promoting their own repo is not wrong neither.
Keep in mind that whoever's repo you add gets root access to your system.
And that's different from the flash pullin package... how?
Up to then we were shipping it after review, so you only needed to trust openSUSE. Now you also trust Adobe more explicitly. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 3, 2015 at 11:02 AM, Marcus Meissner
On Tue, Nov 03, 2015 at 10:53:57AM -0300, Claudio Freire wrote:
On Tue, Nov 3, 2015 at 4:06 AM, Ludwig Nussel
wrote: Am 02.11.2015 um 11:55 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer.
And honoring the work done by Adobe by promoting their own repo is not wrong neither.
Keep in mind that whoever's repo you add gets root access to your system.
And that's different from the flash pullin package... how?
Up to then we were shipping it after review, so you only needed to trust openSUSE.
Now you also trust Adobe more explicitly.
You actually reviewed the binary? I'm impressed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 03, 2015 at 11:11:10AM -0300, Claudio Freire wrote:
On Tue, Nov 3, 2015 at 11:02 AM, Marcus Meissner
wrote: On Tue, Nov 03, 2015 at 10:53:57AM -0300, Claudio Freire wrote:
On Tue, Nov 3, 2015 at 4:06 AM, Ludwig Nussel
wrote: Am 02.11.2015 um 11:55 schrieb Dominique Leuenberger / DimStar:
On Mon, 2015-11-02 at 11:49 +0100, Martin Schlander wrote:
As long as Packman provide the package I'm leaning towards pushing users in that direction. Since they'll have that repo anyway, and there won't be confusion about people having 'flash-plugin' from Adobe vs. 'flash- player' from Packman.
Will they? Don't extrapolate from your use-cases to others... I don't run PM on any of my systems for example.. PM is repo like any others with, imho, not more priority than what others offer.
And honoring the work done by Adobe by promoting their own repo is not wrong neither.
Keep in mind that whoever's repo you add gets root access to your system.
And that's different from the flash pullin package... how?
Up to then we were shipping it after review, so you only needed to trust openSUSE.
Now you also trust Adobe more explicitly.
You actually reviewed the binary?
I'm impressed.
No, but the library only runs as desktop user. Installing the RPM however runs as "root". So before we all trusted Adobe at the "user" level, and now we trust them at the "root" level. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 3 15:14 Marcus Meissner wrote (excerpt):
On Tue, Nov 3, 2015 at 4:06 AM, Ludwig Nussel
wrote: Keep in mind that whoever's repo you add gets root access to your system.
... the library only runs as desktop user.
Installing the RPM however runs as "root".
So before we all trusted Adobe at the "user" level, and now we trust them at the "root" level.
I wonder if on an usual end-user system (i.e. on a system where the Adobe Flash Player normally is used) there is in practice a real difference when malware runs as "the user" versus when it runs as "root"? I think the real value on a computer is user data (like private data, in particular private secrets) and not system data like programs or config files because the latter can relatively easily be recreated (re-install from scratch if the system got corrupted). Perhaps when malware runs as the user it could be even worse than when malware runs as root because when malware runs as the user it might be even easier to steal private user data under certain circumstances? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 3, 2015 at 11:47 AM, Johannes Meixner
Hello,
On Nov 3 15:14 Marcus Meissner wrote (excerpt):
On Tue, Nov 3, 2015 at 4:06 AM, Ludwig Nussel
wrote: Keep in mind that whoever's repo you add gets root access to your system.
... the library only runs as desktop user.
Installing the RPM however runs as "root".
So before we all trusted Adobe at the "user" level, and now we trust them at the "root" level.
I wonder if on an usual end-user system (i.e. on a system where the Adobe Flash Player normally is used) there is in practice a real difference when malware runs as "the user" versus when it runs as "root"?
I think the real value on a computer is user data (like private data, in particular private secrets) and not system data like programs or config files because the latter can relatively easily be recreated (re-install from scratch if the system got corrupted).
Perhaps when malware runs as the user it could be even worse than when malware runs as root because when malware runs as the user it might be even easier to steal private user data under certain circumstances?
When someone runs as root it can compromise the whole system, whereas something that runs as a user can only compromise the user. Furthermore, the ability to hide from plain sight for malware running as user is greatly diminished, whereas one running as root can almost perfectly hide from sight. So, it is worse to get rooted even on a single-user system, because those infections can hide better. So I guess there's that. Adobe could root you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 3 11:50 Claudio Freire wrote (excerpt):
On Tue, Nov 3, 2015 at 11:47 AM, Johannes Meixner
wrote: I wonder if on an usual end-user system (i.e. on a system where the Adobe Flash Player normally is used) there is in practice a real difference when malware runs as "the user" versus when it runs as "root"?
I think the real value on a computer is user data (like private data, in particular private secrets) and not system data like programs or config files because the latter can relatively easily be recreated (re-install from scratch if the system got corrupted).
Perhaps when malware runs as the user it could be even worse than when malware runs as root because when malware runs as the user it might be even easier to steal private user data under certain circumstances?
When someone runs as root it can compromise the whole system,
Really in any case? Of course on a system with only traditional file access permissions root can read all files because for root traditional file access permissions are not tested. But I wonder if there is perhaps nowadays advanced stuff which could protect user data even from root access?
whereas something that runs as a user can only compromise the user.
My argument is that "only compromise the user" is in practice on an usual end-user system the worst case. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 3, 2015 at 1:07 PM, Johannes Meixner
whereas something that runs as a user can only compromise the user.
My argument is that "only compromise the user" is in practice on an usual end-user system the worst case.
It's not the worst case. But it is probably quite disastrous anyway. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-03 17:46, Claudio Freire wrote:
On Tue, Nov 3, 2015 at 1:07 PM, Johannes Meixner <> wrote:
whereas something that runs as a user can only compromise the user.
My argument is that "only compromise the user" is in practice on an usual end-user system the worst case.
It's not the worst case. But it is probably quite disastrous anyway.
It depends. An attack that destroys the user data files is horrendous. If it destroys the system, it is simple to format and recover the system, even without having a backup. It just takes time. Of course, malware with root access could do anything. But if the machine turns into a bot sending spam mail, well... I know of many people that do not care at all about that issue. It bothers other people but not "the user", they say. No kidding! -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hello, On Nov 3 19:41 Carlos E. R. wrote (excerpt):
An attack that destroys the user data files is horrendous. If it destroys the system, it is simple to format and recover the system, even without having a backup. It just takes time.
I do not fully agree. An attack that destroys user data is only an annoyance. It is simple to be detected and simple to be fixed by restoring the backup. But I do agree that an attack that destroys the system is only an annoyance (simple to be detected and fixed). The worst case is an attack that reads (steals) secrets. My basic question is whether or not there is nowadays "appropriate stuff" that can be used to protect user data even from being read by root so that malware that runs as root cannot read the protected user data? Because I am talking about an usual end-user system I mean when malware runs as root while at the same time the end-user is using the system. I think on an usual end-user system it is nowadays not possible to protect the user from root because root could always eavesdrop on all user input via whatever changes in the basic system (e.g. a keylogger in the kernel). Or might perhaps "UEFI Secure Boot" help here? I am thinking about Lennart Poettering talk on FOSDEM 2015 about adding Gummiboot to systemd to complete the safety chain of the boot process with UEFI Secure Boot. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-04 12:36, Johannes Meixner wrote:
Hello,
On Nov 3 19:41 Carlos E. R. wrote (excerpt):
An attack that destroys the user data files is horrendous. If it destroys the system, it is simple to format and recover the system, even without having a backup. It just takes time.
I do not fully agree.
An attack that destroys user data is only an annoyance. It is simple to be detected and simple to be fixed by restoring the backup.
Most people do not have a backup, or it is not recent enough. Even a week of work lost can be dramatic, if it happens at the /right/ moment.
But I do agree that an attack that destroys the system is only an annoyance (simple to be detected and fixed).
The worst case is an attack that reads (steals) secrets.
Yes. The email password can be key to open other doors, for instance.
My basic question is whether or not there is nowadays "appropriate stuff" that can be used to protect user data even from being read by root so that malware that runs as root cannot read the protected user data?
Telcontar:~ # l /run/user/1000/gvfs ls: cannot access /run/user/1000/gvfs: Permission denied Telcontar:~ # ??
Because I am talking about an usual end-user system I mean when malware runs as root while at the same time the end-user is using the system.
True.
Or might perhaps "UEFI Secure Boot" help here?
Dunno. I have seen schemes to thwart that. Mostly social engineering, if I remember right. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, 2015-11-04 at 14:27 +0100, Carlos E. R. wrote:
My basic question is whether or not there is nowadays
"appropriate stuff" that can be used to protect user data even from being read by root so that malware that runs as root cannot read the protected user data?
Telcontar:~ # l /run/user/1000/gvfs ls: cannot access /run/user/1000/gvfs: Permission denied Telcontar:~ #
gvfs is a bit different to normal directories - it's actually a fuse mount point. fuse per default only gives access to the user - root is blocked out there. In 'essence', the fuse FS driver running in user space, is the only one having the credentials to access the remote instance (could be really remote for example). Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 04.11.2015 um 14:39 schrieb Dominique Leuenberger / DimStar:
fuse per default only gives access to the user - root is blocked out there. In 'essence', the fuse FS driver running in user space, is the only one having the credentials to access the remote instance (could be really remote for example).
But if you are root, this "protection" is easily worked around. So it in the best case can prevent accidents, but not attacks. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 3. November 2015 schrieb Johannes Meixner:
On Nov 3 11:50 Claudio Freire wrote (excerpt):
When someone runs as root it can compromise the whole system,
Really in any case?
Of course on a system with only traditional file access permissions root can read all files because for root traditional file access permissions are not tested.
But I wonder if there is perhaps nowadays advanced stuff which could protect user data even from root access?
Well, in theory, you could create an AppArmor profile for rpm. Unfortunately, you'll need to allow it writing files everywhere and also to override traditional file access permissions (capability dac_override) because, well, writing files everywhere is rpm's job, and also installing files which are only readable by a daemon user. You'll also need to allow executing basically everything because of %post etc. scripts. So in practise it's extremely hard to restrict rpm because that would basically mean to break its functionality. The only thing you could try is to deny access to /home/** - assuming that packages typically should not touch anything there. (I never tried or checked if all packages follow this assumption, and actually never tried to create a profile for rpm. Maybe I should try that "just for fun" before the next zypper dup ;-))
whereas something that runs as a user can only compromise the user.
My argument is that "only compromise the user" is in practice on an usual end-user system the worst case.
The difference is a) compromise user data b) compromise user data _and_ compromise the system in a way that the attack can be hidden so you are right that you'll get the same result for the user data, but at least you have a chance to notice that something interesting[tm] happens ;-) Regards, Christian Boltz --
Brauchst Du die sig noch? Ich hab sie nämlich gerade geklaut ;-) JA!! *uff* ich hab sie noch!!! :) [> Christian Boltz und David Haller in suse-linux-faq]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 3 19:43 Christian Boltz wrote (excerpt):
Well, in theory, you could create an AppArmor profile for rpm.
Unfortunately, you'll need to allow it writing files everywhere and also to override traditional file access permissions (capability dac_override) because, well, writing files everywhere is rpm's job, and also installing files which are only readable by a daemon user. You'll also need to allow executing basically everything because of %post etc. scripts.
Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files? Such an AppArmor profile could be enabled before one installs third party software (e.g. additional application programs) where one does not want that any existing stuff is changed. For a nice example where such an AppArmor profile for rpm would have helped Google for "linux printer driver setuid root" (without quotation marks) and you find things like http://it.slashdot.org/story/07/07/18/0319203/major-security-hole-in-samsung... that reads (excerpt): ----------------------------------------------------------------- Posted by ... on Wednesday July 18, 2007 ... It appears that Samsung unified drivers change rights on some parts of the system: After installing the drivers, applications may launch using root rights, without asking any password. ----------------------------------------------------------------- If I remember correctly in particular OpenOffice executables had been changed at that time to run setuid root when installing that third party printer driver software to "make everything just work" for the user. In contrast when installing openSUSE maintenance updates such an AppArmor profile would have to be disabled before.
The only thing you could try is to deny access to /home/** - assuming that packages typically should not touch anything there.
A long time ago an experienced SUSE developer told me: "/home/* is sacrosanct." This means in particular that package installation must not change any user's own files. Probably it is really a good idea to create an AppArmor profile for rpm to deny access to /home/* and see how a default openSUSE installation behaves. Perhaps this could reveal "interesting" results ;-) Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Johannes Meixner
Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files?
How do you do updates then? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello Andreas, On Nov 4 17:48 Andreas Schwab wrote (fullquote):
Johannes Meixner
writes: Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files?
How do you do updates then?
Could you do me a favour and read my mail completely before you reply to small excerpts without context or alternatively do not cut away what I had written that already addresses your concern? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
04.11.2015 19:57, Johannes Meixner пишет:
Hello Andreas,
On Nov 4 17:48 Andreas Schwab wrote (fullquote):
Johannes Meixner
writes: Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files?
How do you do updates then?
Could you do me a favour and read my mail completely before you reply to small excerpts without context or alternatively do not cut away what I had written that already addresses your concern?
Actually I had the same question and I do not see anything in your mail that answers it. How would you update third party RPM with this profile active? You suggest to disable this profile during "installing openSUSE maintenance updates" only. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 4 20:40 Andrei Borzenkov wrote (excerpt):
Johannes Meixner
writes: Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files?
How would you update third party RPM with this profile active?
You cannot. This raises a subsequent issue: I assume it is too complicated (or simply impossible) to have an AppArmor profile for rpm so that rpm cannot change already existing files in other packages. Therefore "updating" third party RPMs with this profile active whould have to be done by first removing the installed third party RPM and then installing the new version of the third party RPM from scratch. I do not know how far this is feasible in practice. In particular it seems there is no rpm erase option like "--excludeconfigfiles" so that one could keep the RPM configfiles after package removal. In contrast all user-specific data is under /home/* where it is safe because /home/* is sacrosanct. Currently I think the sacrosanct status of /home/* for rpm should be probably really enforced by default. In general: When you fully trust a third party (i.e. when you allow that third party to work as root on your system), you can install their RPMs "as usual" (i.e. without such a profile). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-05 11:42, Johannes Meixner wrote:
This raises a subsequent issue:
I assume it is too complicated (or simply impossible) to have an AppArmor profile for rpm so that rpm cannot change already existing files in other packages.
Therefore "updating" third party RPMs with this profile active whould have to be done by first removing the installed third party RPM and then installing the new version of the third party RPM from scratch.
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..." Is that possible? I know it is possible to catch the changes with something like the seccheck scripts that run off cron, but it is heavy processing and would find also changes not done by this install. It would not be the best thing, but knowing what has been changed would allow an administrator to revert the changes, and perhaps write an AA profile that denies those same changes, for the next run. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, Nov 05, 2015 at 01:14:18PM +0100, Carlos E. R. wrote:
On 2015-11-05 11:42, Johannes Meixner wrote:
This raises a subsequent issue:
I assume it is too complicated (or simply impossible) to have an AppArmor profile for rpm so that rpm cannot change already existing files in other packages.
Therefore "updating" third party RPMs with this profile active whould have to be done by first removing the installed third party RPM and then installing the new version of the third party RPM from scratch.
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..."
Is that possible?
I know it is possible to catch the changes with something like the seccheck scripts that run off cron, but it is heavy processing and would find also changes not done by this install.
It would not be the best thing, but knowing what has been changed would allow an administrator to revert the changes, and perhaps write an AA profile that denies those same changes, for the next run.
snapper and btrfs snapshots is made for this and can do this already;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-05 14:02, Marcus Meissner wrote:
snapper and btrfs snapshots is made for this and can do this already;)
Mmm... would not help me, I don't use btrfs. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 05.11.2015 um 14:02 schrieb Marcus Meissner:
snapper and btrfs snapshots is made for this and can do this already;)
This hammer is much too big. It would roll back totally unrelated changes. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 5 13:14 Carlos E. R. wrote (excerpt):
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..."
I assume you mean to basically compare what "rpm -ql" shows for an installed package before updating it with what it shows after it was updated. I think on the one hand this would result too much false-positives warnings or errors when updating an installed RPM because an update can change any files that belong to the package, e.g. things like replacing /opt/<package>/<path>/this by /opt/<package>/<path>/that. On the other hand what should the user do when he gets informed that "update of <package> replaced /usr/bin/ls"? I think the approach to "install the rpm" and do anything afterwards does not really help - except to scare the user after all could have been already lost. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-05 14:09, Johannes Meixner wrote:
Hello,
On Nov 5 13:14 Carlos E. R. wrote (excerpt):
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..."
I assume you mean to basically compare what "rpm -ql" shows for an installed package before updating it with what it shows after it was updated.
Well, no... rpm -ql should display the same before and after. Doesn't it? :-? The issue here, I believe, is what is done by scripts in the rpm, what is not declared in advance.
On the other hand what should the user do when he gets informed that "update of <package> replaced /usr/bin/ls"?
Huh. Freak out? :-))
I think the approach to "install the rpm" and do anything afterwards does not really help - except to scare the user after all could have been already lost.
Well, it is rather for investigation, not for every user. Me, I would prefer to know, even if it is too late. Of course, even better would be to halt mid-install on every outside change, and ask whether to allow or not. But that would extensive new coding, I guess. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hello, Am Donnerstag, 5. November 2015 schrieb Carlos E. R.:
On 2015-11-05 14:09, Johannes Meixner wrote:
On Nov 5 13:14 Carlos E. R. wrote (excerpt):
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..."
I assume you mean to basically compare what "rpm -ql" shows for an installed package before updating it with what it shows after it was updated.
Well, no... rpm -ql should display the same before and after. Doesn't it? :-? The issue here, I believe, is what is done by scripts in the rpm, what is not declared in advance.
It's not declared by rpm -qpl - but you can easily use rpm -qp --scripts untrusted-package.rpm IMHO that is the more important check compared to rpm -qpl because things done by the scripts are typically harder to detect afterwards (rpm -qf $file and rpm -V $package are useless if a script creates or modifies a file, while both are helpful for files "officially" shipped in a package).
On the other hand what should the user do when he gets informed that "update of <package> replaced /usr/bin/ls"?
Huh. Freak out? :-))
And that repairs your system? Does it also work for hacked Joomla or Wordpress sites? If yes, can you teach me how to correctly freak out, please? ;-)
Of course, even better would be to halt mid-install on every outside change, and ask whether to allow or not. But that would extensive new coding, I guess.
The problem is that it will end up in *lots of* questions [1] - and that means that the user will just put a stone on the enter key and miss the one malicious thing in the middle of 100 other events. Regards, Christian Boltz [1] lots of packages have scripts in %post etc. - being it ldconfig calls (done in all lib* packages), updating the bootloader, changing an alternatives symlink, updating font or icon cache, ... --
Heute habe ich die CPU gepflegt und wollte danach den PC starten / booten. Es gab kein Bild. Was heißt das denn genau? Maniküre, Pediküre, UV-Bad, Cremen, ... ;) [> Frank und T. Ermlich in opensuse-de]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-05 23:30, Christian Boltz wrote:
Hello,
Am Donnerstag, 5. November 2015 schrieb Carlos E. R.:
On the other hand what should the user do when he gets informed that "update of <package> replaced /usr/bin/ls"?
Huh. Freak out? :-))
And that repairs your system? Does it also work for hacked Joomla or Wordpress sites? If yes, can you teach me how to correctly freak out, please? ;-)
Of course. You have to scream wildly. Then you may get a contract for Scary Movie 42 ;-)
Of course, even better would be to halt mid-install on every outside change, and ask whether to allow or not. But that would extensive new coding, I guess.
The problem is that it will end up in *lots of* questions [1] - and that means that the user will just put a stone on the enter key and miss the one malicious thing in the middle of 100 other events.
Well, as I said, I'm considering it as tool for investigation, not for end users. Do you remember "checkinstall"? Somehow, it detected what "make install" created. How did it do it? :-? Something wrapping "rpm" so that it could list every file it writes or modifies. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 05.11.2015 um 23:30 schrieb Christian Boltz:
It's not declared by rpm -qpl - but you can easily use rpm -qp --scripts untrusted-package.rpm
have you ever done this with commercial, third-party packages? Example: citrix-receiver. An estimated jigawatt of %post/%pre scripts. Totally unreadable. No fscking way I'm going to install this piece of crap on any of my machines. I instead used the tarballs and installed them in a separate user's home...
[1] lots of packages have scripts in %post etc. - being it ldconfig calls (done in all lib* packages), updating the bootloader, changing an alternatives symlink, updating font or icon cache, ...
Well, one could whitelist packages from known good vendors, e.g. those signed with a particular GPG key. But still complain about packages unsigned or signed with an Adobe, Citrix or Google key. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 05.11.2015 um 13:14 schrieb Carlos E. R.:
On 2015-11-05 11:42, Johannes Meixner wrote:
This raises a subsequent issue:
I assume it is too complicated (or simply impossible) to have an AppArmor profile for rpm so that rpm cannot change already existing files in other packages.
Therefore "updating" third party RPMs with this profile active whould have to be done by first removing the installed third party RPM and then installing the new version of the third party RPM from scratch.
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..."
Is that possible?
Yes. By using the audit subsystem. You can log which process changes which files, then check if it is a child of RPM (you don't want to wade through everything else that's going on on a busy file server while installing Flash Player on it ;-P), and if it is, log everything that's change. Then, after rpm is finished installing, use this log and compare it to what the package actually claims to have done. Combine this with a snapper snapshot before and after the installation and it should be possible to restore things to a working order afterwards. Or maybe with some help of a kernel driver, we could even intercept all the calls that a certain process does (in this case rpm and its children) and create a backup of every file that is touched by the installation (this is not possible AFAIK by just using audit, because audit only *notifies* you of changes, but there is no way to intercept the calls, so once you are notified, the file is already modified, too late to back up).
I know it is possible to catch the changes with something like the seccheck scripts that run off cron, but it is heavy processing and would find also changes not done by this install.
Exactly. And you would not know who had done the changes. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-06 18:50, Stefan Seyfried wrote:
Am 05.11.2015 um 13:14 schrieb Carlos E. R.:
Different approach idea: install the rpm and somehow list or catch any written or changed file outside of those listed by "rpm -ql ..."
Is that possible?
Yes. By using the audit subsystem. You can log which process changes which files, then check if it is a child of RPM (you don't want to wade through everything else that's going on on a busy file server while installing Flash Player on it ;-P), and if it is, log everything that's change. Then, after rpm is finished installing, use this log and compare it to what the package actually claims to have done. Combine this with a snapper snapshot before and after the installation and it should be possible to restore things to a working order afterwards.
Yes, this is what I was thinking about, but I wouldn't know how to do it :-) Ah, another way to check changes and undo them is rpm --verify, and those changed, reinstall. Clumsy, but doable. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hello, Am Mittwoch, 4. November 2015 schrieb Johannes Meixner:
On Nov 3 19:43 Christian Boltz wrote (excerpt):
Well, in theory, you could create an AppArmor profile for rpm.
Unfortunately, you'll need to allow it writing files everywhere and also to override traditional file access permissions (capability dac_override) because, well, writing files everywhere is rpm's job, and also installing files which are only readable by a daemon user. You'll also need to allow executing basically everything because of %post etc. scripts.
Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files?
w (write) permissions always allow creating and changing a file. In theory, a (append) might work - it allows creating a file and appending to it (so not exactly what you want, the typical usecase for 'a' permissions are logfiles). However it could be problematic if rpm also needs to change the file permissions or owner afterwards because that will need w permissions.
Such an AppArmor profile could be enabled before one installs third party software (e.g. additional application programs) where one does not want that any existing stuff is changed.
If you really want that, it might be possible to create a profile based on the rpm -qpl output, but that won't help much for %post scripts. Well, except if your goal is not to let %post change anything that is not related to the new package, ... ;-)
For a nice example where such an AppArmor profile for rpm would have helped Google for "linux printer driver setuid root" (without quotation marks) and you find things like http://it.slashdot.org/story/07/07/18/0319203/major-security-hole-in-s amsung-linux-drivers that reads (excerpt): ----------------------------------------------------------------- Posted by ... on Wednesday July 18, 2007 ... It appears that Samsung unified drivers change rights on some parts of the system: After installing the drivers, applications may launch using root rights, without asking any password. ----------------------------------------------------------------- If I remember correctly in particular OpenOffice executables had been changed at that time to run setuid root when installing that third party printer driver software to "make everything just work" for the user.
Oh, nice! Speaking about printer drivers - do you think having a profile for cups would be possible? Would you be willing to test it? (I "only" have a boring setup with one printer at the other end of the network cable ;-) so I can only do some tests for this type of setup.)
In contrast when installing openSUSE maintenance updates such an AppArmor profile would have to be disabled before.
Obviously ;-) BTW: aa-exec allows you to invoke a program with a specific profile. That's probably easier than switching profiles on and off.
The only thing you could try is to deny access to /home/** - assuming that packages typically should not touch anything there.
A long time ago an experienced SUSE developer told me:
"/home/* is sacrosanct."
This means in particular that package installation must not change any user's own files.
Probably it is really a good idea to create an AppArmor profile for rpm to deny access to /home/* and see how a default openSUSE installation behaves.
Perhaps this could reveal "interesting" results ;-)
OK, challenge accepted.
Note that the profile is a bit quick&dirty - if I'd want to use it for
more than this "because we can" mail, I'd do some things in more clean
ways, for example avoiding some of the wildcard usage and putting rpm
into a subprofile.
# cat /etc/apparmor.d/shm-install
# Last Modified: Wed Nov 4 21:49:59 2015
#include
Christian Boltz
If you really want that, it might be possible to create a profile based on the rpm -qpl output, but that won't help much for %post scripts.
An rpm can also take ownership of any existing file in the system. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Nov 4 23:45 Christian Boltz wrote (excerpt):
Am Mittwoch, 4. November 2015 schrieb Johannes Meixner:
Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files?
... If you really want that, it might be possible to create a profile based on the rpm -qpl output, but that won't help much for %post scripts. Well, except if your goal is not to let %post change anything that is not related to the new package, ... ;-)
Yes, my goal is not to let %post change anything that is not related to the new package because otherwise anything evil could be done via RPM scriptlets. For my personal use case see https://fate.opensuse.org/307745 (excerpt) ------------------------------------------------------------------ ... it downloads RPMs only from hardcoded URLs from OpenPrinting and inspects the downloaded RPM whether it overwrites already installed files on the system and if not, it installs it without running any RPM scripts because normal printer drivers do not need to run RPM scripts during installation. If the above conditions are not fulfilled it shows a very explicite warning text and does not install anything. ------------------------------------------------------------------ Normal printer driver software packages do not need to run RPM scriptlets. Perhaps also for installing normal application prgrams there is no real need to run RPM scriptlets. The only exception is perhaps running /sbin/ldconfig in %post and %postun. But I wonder if this could be misused to do evil things, e.g. when third-party software provides its own version of a standard library with "special additional functionality" (a.k.a. backdoor).
Speaking about printer drivers - do you think having a profile for cups would be possible?
I do not yet understand what you mean with "a profile for cups" i.e. what your intent behind such a profile should be.
In contrast when installing openSUSE maintenance updates such an AppArmor profile would have to be disabled before.
Obviously ;-)
BTW: aa-exec allows you to invoke a program with a specific profile. That's probably easier than switching profiles on and off.
Perhaps a more general feature request like https://fate.opensuse.org/307745 for "a general tool" (not necessarily a YaST module) that helps a normal user to install third-party software in a reasonably secure way (what "reasonably secure" is needs to be discussed and defined) makes sense?
Probably it is really a good idea to create an AppArmor profile for rpm to deny access to /home/* and see how a default openSUSE installation behaves.
Perhaps this could reveal "interesting" results ;-)
OK, challenge accepted. ... ... basically with the same result:
A default tumbleweed install with KDE does not touch anything inside /home :-)
Wow! We are really good!
A funny detail is that some %post script creates /dev/lp* - any idea why that might be needed? For bonus points, tell me which package does that, and why /dev/lp* are needed on a laptop that doesn't have a parallel port ;-)
See https://bugzilla.opensuse.org/show_bug.cgi?id=673845 for the full story. You need to find out why you got the parallel-printer-support RPM installed on your computer. As far as I know installation of this RPM is not done in a hardware dependant way but by a RPM "recommends" (actually by a "Supplements: cups"). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 5. November 2015 schrieb Johannes Meixner:
On Nov 4 23:45 Christian Boltz wrote (excerpt):
Am Mittwoch, 4. November 2015 schrieb Johannes Meixner:
Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files? ... If you really want that, it might be possible to create a profile based on the rpm -qpl output, but that won't help much for %post scripts. Well, except if your goal is not to let %post change anything that is not related to the new package, ... ;-)
Yes, my goal is not to let %post change anything that is not related to the new package because otherwise anything evil could be done via RPM scriptlets.
For my personal use case see https://fate.opensuse.org/307745 (excerpt) ------------------------------------------------------------------ ... it downloads RPMs only from hardcoded URLs from OpenPrinting and inspects the downloaded RPM whether it overwrites already installed files on the system and if not, it installs it without running any RPM scripts because normal printer drivers do not need to run RPM scripts during installation. If the above conditions are not fulfilled it shows a very explicite warning text and does not install anything. ------------------------------------------------------------------
Normal printer driver software packages do not need to run RPM scriptlets.
That sounds like rpm -Uhv --noscripts printer-driver.rpm ;-) (and checking rpm -qpl printer-driver.rpm before actually installing it)
Perhaps also for installing normal application prgrams there is no real need to run RPM scriptlets.
The only exception is perhaps running /sbin/ldconfig in %post and %postun.
And fontconfig and update-desktop-files and ... ;-) As I showed yesterday, it is possible to create a profile for zypper or rpm, however it needs to be quite broad ("allow write access to everything except /home/**, and also allow to execute several things called in %post"). It should be possible to generate a profile based on rpm -qpl [1], and maybe even separate subprofiles for things typically called in %post (so that ldconfig can only write /etc/ld.so.cache), but I wonder if it's really worth the effort. The problem with such a profile is that it _will_ deny/break something sooner or later, so I'm afraid the chance that people actually use it is not too high... Having a basic rpm profile ("allow everything outside of /home") might be an option, but even that could break something if someone invents a a new creative way to use %post. Hmm, maybe I should really create an apparmor-profiles-paranoid package one day ;-)
But I wonder if this could be misused to do evil things, e.g. when third-party software provides its own version of a standard library with "special additional functionality" (a.k.a. backdoor).
If that backdoor is inside the third-party software, then checking things at installation time is useless (assuming it installs that backdoored library in a private directory, not in /usr/lib/). Instead, you might want to create a (strict [2]) AppArmor profile for this software ;-)
Speaking about printer drivers - do you think having a profile for cups would be possible?
I do not yet understand what you mean with "a profile for cups" i.e. what your intent behind such a profile should be.
I'm thinking about an AppArmor profile that allows cups to do only what it is supposed to do (take print data from an application, convert it to a format the printer understands, and send it to the printer). This implicitely means to deny everything else. With such a profile, ideally even malicious printer drivers could "only" access the to-be-printed data, but not everything else. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/view/head... is probably a good starting point, however I didn't test it yet. The Ux (unconfined) rule used for third-party backends and some other Ux rules look too permissive to me - and that's where you would be able to help a lot because you know a lot about cups and possibly also know (or even can test) lots of third-party printer drivers. Needless to say that the footnote [2] about the strictness of the profile also applies to cups, and that's probably why Ubuntu chose to use those Ux rules.
In contrast when installing openSUSE maintenance updates such an AppArmor profile would have to be disabled before.
Obviously ;-)
BTW: aa-exec allows you to invoke a program with a specific profile. That's probably easier than switching profiles on and off.
Perhaps a more general feature request like https://fate.opensuse.org/307745 for "a general tool" (not necessarily a YaST module) that helps a normal user to install third-party software in a reasonably secure way (what "reasonably secure" is needs to be discussed and defined) makes sense?
See above - I'd call rpm -Uhv --noscripts reasonable secure ;-) Having an AppArmor profile based on rpm -qpl is something people using permissions.paranoid might want ;-)
A funny detail is that some %post script creates /dev/lp* - any idea why that might be needed? For bonus points, tell me which package does that, and why /dev/lp* are needed on a laptop that doesn't have a parallel port ;-)
See https://bugzilla.opensuse.org/show_bug.cgi?id=673845 for the full story.
That's a quite long story ;-) (short version: without /dev/lp*, parallel port printers can't be auto-detected)
You need to find out why you got the parallel-printer-support RPM installed on your computer. As far as I know installation of this RPM is not done in a hardware dependant way but by a RPM "recommends" (actually by a "Supplements: cups").
Right, parallel-printer-support has Supplements: cups. Now the obvious question is if we can change the installation of this package to a hardware-dependent way ;-) Regards, Christian Boltz [1] We already have a script that generates a sniplet for the samba profile based on smb.conf. Converting the rpm -qpl output to a profile sniplet is probably easier ;-) [2] "strict" is exactly the problem - a paranoid user might like a profile for his webbrowser that allows writing files only to ~/download and reading files only from ~/public, and another user will find this restriction extremely annoying ;-) -- "Der Unterschied zwischen einem Windows- und Linux-User ist der, daß ein Linux-User lesen kann!" [Frank Gerd Walzebuck in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, becomes now probably too much off-topic because now it is mainly about printer drivers and CUPS. On Nov 6 01:02 Christian Boltz wrote (excerpt):
Normal printer driver software packages do not need to run RPM scriptlets.
That sounds like rpm -Uhv --noscripts printer-driver.rpm
Of course - except running /sbin/ldconfig if needed.
The only exception is perhaps running /sbin/ldconfig in %post and %postun.
And fontconfig and update-desktop-files and ... ;-)
Here I was talking about printer driver software packages not about arbitrary third party RPMs.
Having a basic rpm profile ("allow everything outside of /home") might be an option, but even that could break something if someone invents a a new creative way to use %post.
But when the intent is to "forbid changing anything in /home/" then it must break installing RPMs that would change something in /home/ - or what do I misunderstand here?
Speaking about printer drivers - do you think having a profile for cups would be possible?
I do not yet understand what you mean with "a profile for cups" i.e. what your intent behind such a profile should be.
I'm thinking about an AppArmor profile that allows cups to do only what it is supposed to do (take print data from an application, convert it to a format the printer understands, and send it to the printer).
As far as I know the cupsd implements already some limitations what filters and backends can do. Furthermore normally installed filters and backends run as user "lp" which means they are already sufficiently restricted by traditional Unix file permission settings. Regarding the cupsd itself: It runs intentionally as root because - only root can switch user to lp so that this way the filters and backends cannot compromise the cupsd itself (e.g. its config files). - the cupsd does more than what you described. In general we have this discussion every now and then again and again and again and again and again and again... And the result is always the same: The current defaults are the currently best possible balance between reasonable default security and reasonable user-friendly default behaviour. Any attempt to make CUPS more secure by default causes complaints that then this or that functionality doe no longer work out of the box and any attempt to make CUPS more user-friendly by default makes it unacceptable less secure by default.
With such a profile, ideally even malicious printer drivers could "only" access the to-be-printed data, but not everything else.
First and foremost you would need to describe how a program that runs as "lp" could do "everything else" or what exactly you mean with "everything else".
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/view/head...
I wonder why they need an Apparmor profile for CUPS. With "why" I mean their reasoning behind. I wonder what might be wrong in CUPS itself that is not discussed on the CUPS upstream development list and cannot be fixed in CUPS itself so that the only way out for them is to use an AppArmor profile? I think I will ask Martin Pitt and Till Kamppeter about their reasoning behind. In general regarding SUSE's printing system see "User expectations" at https://en.opensuse.org/Concepts_printing
A funny detail is that some %post script creates /dev/lp* - any idea why that might be needed? For bonus points, tell me which package does that, and why /dev/lp* are needed on a laptop that doesn't have a parallel port ;-)
See https://bugzilla.opensuse.org/show_bug.cgi?id=673845 for the full story.
That's a quite long story ;-) (short version: without /dev/lp*, parallel port printers can't be auto-detected)
Not "device auto-detection" but "kernel module auto-loading". Without /dev/lp* parallel port printers cannot work because without /dev/lp* the lp kernel module gets not loaded. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 6. November 2015 schrieb Johannes Meixner:
becomes now probably too much off-topic because now it is mainly about printer drivers and CUPS.
This thread already got quite some off-topic discussions, therefore I don't see a real problem. However, I'll update the subject ;-)
On Nov 6 01:02 Christian Boltz wrote (excerpt):
Normal printer driver software packages do not need to run RPM scriptlets.
That sounds like rpm -Uhv --noscripts printer-driver.rpm
Of course - except running /sbin/ldconfig if needed.
The only exception is perhaps running /sbin/ldconfig in %post and %postun.
And fontconfig and update-desktop-files and ... ;-)
Here I was talking about printer driver software packages not about arbitrary third party RPMs.
I already see someone requesting a sandbox for installing font packages, so we should not limit this to "just printer drivers". (I know there are more third-party printer driver RPMs than font RPMs, but still.)
Having a basic rpm profile ("allow everything outside of /home") might be an option, but even that could break something if someone invents a a new creative way to use %post.
But when the intent is to "forbid changing anything in /home/" then it must break installing RPMs that would change something in /home/ - or what do I misunderstand here?
No misunderstanding. In the previous mails you said that RPMs should *never* touch anything inside /home/. Therefore I'd call that restriction "enforcing a policy", not "breaking something" ;-)
I'm thinking about an AppArmor profile that allows cups to do only what it is supposed to do (take print data from an application, convert it to a format the printer understands, and send it to the printer).
As far as I know the cupsd implements already some limitations what filters and backends can do.
Furthermore normally installed filters and backends run as user "lp" which means they are already sufficiently restricted by traditional Unix file permission settings.
I know at least one exception - cups-pdf writes the resulting PDF files to each user's homedir, so it can't run as user 'lp'.
Regarding the cupsd itself: It runs intentionally as root because - only root can switch user to lp so that this way the filters and backends cannot compromise the cupsd itself (e.g. its config files).
I'd argue that it could run as "lp" from the beginning - that would be (at least) equally secure and wouldn't even need to switch users. (I'm sure there are reasons why it's running as root - but "can switch to 'lp'" is not a real reason.)
- the cupsd does more than what you described.
I know that I provided a very quick (and possibly incomplete) summary, but basically it describes what most users see and know about CUPS.
In general we have this discussion every now and then again and again and again and again and again and again...
And the result is always the same: The current defaults are the currently best possible balance between reasonable default security and reasonable user-friendly default behaviour.
Any attempt to make CUPS more secure by default causes complaints that then this or that functionality doe no longer work out of the box and any attempt to make CUPS more user-friendly by default makes it unacceptable less secure by default.
Agreed, there is always the balance between security and being user- friendly. (See also permissions.{easy,secure,paranoid}.) And ideally an AppArmor profile would allow everything that CUPS usually does, so it won't change anything from the user's POV.
With such a profile, ideally even malicious printer drivers could "only" access the to-be-printed data, but not everything else.
First and foremost you would need to describe how a program that runs as "lp" could do "everything else" or what exactly you mean with "everything else".
For example, it could read files from the home directory if the unix permissions allow this (755), and could then send those files to an attacker. The point is: Even if running as 'lp', it can access data that it shouldn't be able to - and that's where an AppArmor profile could be helpful.
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/v iew/head:/debian/local/apparmor-profile I wonder why they need an Apparmor profile for CUPS. With "why" I mean their reasoning behind. I wonder what might be wrong in CUPS itself that is not discussed on the CUPS upstream development list and cannot be fixed in CUPS itself so that the only way out for them is to use an AppArmor profile?
The answer is probably https://startpage.com/do/search?q=cups+exploit and especially the things that are not yet listed there (in other words: unknown security flaws in CUPS). I know that nobody intentionally writes buggy code, but it's a fact that all software has bugs [1], and some of them can be exploited. AppArmor can at least prevent exploits that access files which are not allowed in the profile and therefore reduce the possible damage. (It can also deny other things like network access / "sending out files", but we probably have to allow network usage for CUPS to support network printers.)
I think I will ask Martin Pitt and Till Kamppeter about their reasoning behind.
Please do that, I'm also interested in the answer ;-) (I wouldn't be surprised if the answer is "additional security".) Regards, Christian Boltz [1] well, a simple hello_world.py is probably bug-free [2] ;-) but anything bigger than that has a good chance to contain bugs. [2] even that could be incompatible with python 3.x ;-) -- liegt es vielleicht an den lauschigen 34°, die der Prozessor oder sowas nicht mitmacht? -> Soll ich mit dem Rechner jetzt zum Baggersee rausfah- ren und ihm ne Abkühlung verpassen... [Sebastian Schulze in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 02 novembre 2015 à 12:51 +0300, Andrei Borzenkov a écrit :
On Mon, Nov 2, 2015 at 12:32 PM, Frederic Crozat
wrote: I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on
As far as I understood this RPM still requires manual link for browser plugin, at least that is what Carlos wrote. Looking at RPMs
Adobe install browser into /usr/lib64/flash-plugin/libflashplayer.so
openSUSE RPM installs it into
install -Dm 0644 libflashplayer.so %{buildroot}%{_libdir}/browser-plugins/libflashplayer.so
No, it is not needed, the setup script run in %post is handling the symlink creation (I checked ;)
there are also some cosmetic improvements in openSUSE RPM regarding DE integration.
To be honest, I'm not sure it is worth it ;) And I prefer to trade this in exchange of "up to date" package regarding security fixes.. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-11-02 12:42, Frederic Crozat wrote:
Adobe install browser into /usr/lib64/flash-plugin/libflashplayer.so
openSUSE RPM installs it into
install -Dm 0644 libflashplayer.so %{buildroot}%{_libdir}/browser-plugins/libflashplayer.so
No, it is not needed, the setup script run in %post is handling the symlink creation (I checked ;)
Mmm. I wonder why it did not do so in my case :-?
there are also some cosmetic improvements in openSUSE RPM regarding DE integration.
To be honest, I'm not sure it is worth it ;)
And I prefer to trade this in exchange of "up to date" package regarding security fixes..
It is certainly less work on maintainers :-) Dunno, but IMO I would keep all the options documented, and then users can decide. I know people that refuse to enable packman, and build the packages themselves, locally... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
* Frederic Crozat
I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on openSUSE and is even providing a yum repository which is working nicely with zypper.
The simplest way is to direct users to do: zypper ar --check --refresh http://linuxdownload.adobe.com/linux/x86_64/ adobe
then zypper in flash-plugin
and that's it. This way, we know the flash plugin will ALWAYS be up to date, until Adobe decided to kill it in the future.
I've taken the liberty to edit the wiki page to add this option as the first option (and removed the "local repository" option, since there is no point in documenting this).
zypper ar --check --refresh http://linuxdownlo9ad.adobe.com/linux/x86_64/ adobe Adding repository 'adobe' ....................................................................[done] Can't find a valid repository at given location: [adobe|http://linuxdownlo9ad.adobe.com/linux/x86_64/] Repository type can't be determined. Could not determine the type of the repository. Please check if the defined URIs (see below) point to a valid repository:http://linuxdownlo9ad.adobe.com/linux/x86_64/ Also doesn't work: http://linuxdownload.adobe.com/linux/ -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/02/2015 09:17 AM, Patrick Shanahan wrote:
* Frederic Crozat
[11-02-15 04:35]: [...] I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on openSUSE and is even providing a yum repository which is working nicely with zypper.
The simplest way is to direct users to do: zypper ar --check --refresh http://linuxdownload.adobe.com/linux/x86_64/ adobe
then zypper in flash-plugin
and that's it. This way, we know the flash plugin will ALWAYS be up to date, until Adobe decided to kill it in the future.
I've taken the liberty to edit the wiki page to add this option as the first option (and removed the "local repository" option, since there is no point in documenting this).
zypper ar --check --refresh http://linuxdownlo9ad.adobe.com/linux/x86_64/ adobe ^
I don't think the number "9" belongs there. :-) -- Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Patrick Shanahan [02.11.2015 15:17]:
* Frederic Crozat
[11-02-15 04:35]: [...] I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on openSUSE and is even providing a yum repository which is working nicely with zypper.
The simplest way is to direct users to do: zypper ar --check --refresh http://linuxdownload.adobe.com/linux/x86_64/ adobe
then zypper in flash-plugin
and that's it. This way, we know the flash plugin will ALWAYS be up to date, until Adobe decided to kill it in the future.
I've taken the liberty to edit the wiki page to add this option as the first option (and removed the "local repository" option, since there is no point in documenting this).
zypper ar --check --refresh http://linuxdownlo9ad.adobe.com/linux/x86_64/ adobe Adding repository 'adobe' ....................................................................[done] Can't find a valid repository at given location: [adobe|http://linuxdownlo9ad.adobe.com/linux/x86_64/] Repository type can't be determined. Could not determine the type of the repository. Please check if the defined URIs (see below) point to a valid repository:http://linuxdownlo9ad.adobe.com/linux/x86_64/
Also doesn't work: http://linuxdownload.adobe.com/linux/
Avoid the typo in your first command and try again :p There is a 9 too much... --
* Patrick Shanahan
* Frederic Crozat
[11-02-15 04:35]: [...] I don't understand why bother shipping Flash Player from Packman, since adobe is doing a rpm package which is working out of the box on openSUSE and is even providing a yum repository which is working nicely with zypper.
The simplest way is to direct users to do: zypper ar --check --refresh http://linuxdownload.adobe.com/linux/x86_64/ adobe
then zypper in flash-plugin
and that's it. This way, we know the flash plugin will ALWAYS be up to date, until Adobe decided to kill it in the future.
I've taken the liberty to edit the wiki page to add this option as the first option (and removed the "local repository" option, since there is no point in documenting this).
zypper ar --check --refresh http://linuxdownlo9ad.adobe.com/linux/x86_64/ adobe
Tks, I now see the very obvious "9". Paint me "Egg on Face" :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Carlos E. R."
The second file contains:
[adobe-linux-x86_64] name=Adobe Systems Incorporated baseurl=http://linuxdownload.adobe.com/linux/x86_64/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
That link gives "forbidden". I don't know if it would work with zypper or not, I haven't checked that far.
The server probably just doesn't allow directory listings. The real meta data is contained in http://linuxdownload.adobe.com/linux/x86_64/repodata/repomd.xml. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-28 11:32, Andreas Schwab wrote:
"Carlos E. R." <> writes:
That link gives "forbidden". I don't know if it would work with zypper or not, I haven't checked that far.
The server probably just doesn't allow directory listings.
Yes, I thought so, but I did not check :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tuesday 2015-10-27 12:24, Stefan Zimmer wrote:
well, it's not youtube, but what about other sites, for example golem.de or spiegel.de? Both very popular news sites in germany.
youtube-dl https://video.golem.de/wissenschaft/16152/gewebe-drucken-mit-dem-makerbot.ht... => success youtube-dl http://www.spiegel.de/video/laub-drohne-ersetzt-besen-video-1620578.html => success youtube-dl http://www.spiegel.tv/filme/insider-raserszene-hamburg/ => no support => BUT: Flash crashes in the browser, too. So: Shit outta luck on this one. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Tirsdag den 27. oktober 2015 12:35:33 skrev Jan Engelhardt:
On Tuesday 2015-10-27 12:24, Stefan Zimmer wrote:
well, it's not youtube, but what about other sites, for example golem.de or spiegel.de? Both very popular news sites in germany.
youtube-dl https://video.golem.de/wissenschaft/16152/gewebe-drucken-mit-dem-makerbot.ht ml => success
youtube-dl http://www.spiegel.de/video/laub-drohne-ersetzt-besen-video-1620578.html => success
youtube-dl http://www.spiegel.tv/filme/insider-raserszene-hamburg/ => no support => BUT: Flash crashes in the browser, too. So: Shit outta luck on this one.
Wow. Youtube-dl even seems to work on dr.dk (Danish national television) I never even bothered to try that before. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/27/2015, 12:15 PM, Bjørn Lie wrote:
I've been using html5 only on youtube for ages, and I've yet to come across a video I can't play without flash, but I might have been lucky.
Could someone please send a link for such a video on youtube.com? Because I suspect that this was true in the past, but not anymore.
Are you lucky to play any 1080p video in 1080p? -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
ti., 27.10.2015 kl. 14.24 +0100, skrev Jiri Slaby:
On 10/27/2015, 12:15 PM, Bjørn Lie wrote:
I've been using html5 only on youtube for ages, and I've yet to come across a video I can't play without flash, but I might have been lucky.
Could someone please send a link for such a video on youtube.com? Because I suspect that this was true in the past, but not anymore.
Are you lucky to play any 1080p video in 1080p?
http://paste.opensuse.org/25887500 Works for me :-) //Bjørn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 26, 2015 at 11:04 AM, Robert Kaiser
Richard Brown schrieb:
On 26 October 2015 at 14:45, Robert Kaiser
wrote: Thanks, this means a lot of people will continue to have the current version installed "until the end of time",even once it becomes horribly insecure. :(
Dude, it's flash, it's been horribly insecure since the beginning of time ;)
That may be the case, but a ton of web content unfortunately relies on it. I'd be one of the first people to cheer if Flash would be really obsolete in this world, but even I have to run two things right at this moment (a game and a sports video player) that require Flash.
It's still far safer if you explicitly acknowledge your permission to run flash by clicking on the appropriate link on FF. Having it disabled by default, 1 click away from running, isn't such a bad thing. At least until everyone moves away from flash. Which will happen quite faster if Adobe takes this stance. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, list, There has already been a way to use chromium-pepper-flash on FF for TW I didn't check Leap, but will do look for "freshplayerplugin" "The main goal of this project is to get PPAPI (Pepper) Flash player working in Firefox. This wrapper implements some kind of adapter which will look like browser to PPAPI plugin and look like NPAPI plugin for browser." Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi all, I also use freshplayerplugin in FF for a while, however it does not work anymore since one of the last TW snapshots :-(. Robby. -- Jabber: robby81@jabber.de -- Vertrauliche Kommunikation ist die Basis der Demokratie! Jede meiner Mails ist mittels PGP signiert. Die Signatur kann einfach mit meinem öffentlichen Schlüssel auf den Standard Key-Servern geprüft werden und zum Senden von verschluesselten Mails an mich genutzt werden. http://www.kuketz-blog.de/verschluesselte-e-mails-mit-gnupg-als-supergrundre... Anleitung für Windows: https://www.youtube.com/watch?v=ieuHHu4MoMo Anleitung für den Mac: https://www.youtube.com/watch?v=3hGlzPzjU-0 Einfach Schlüssel erzeugen uns los geht es ... ----------------------------------------------------- On Monday, October 26, 2015 11:21:18 PM Marguerite Su wrote:
Hi, list,
There has already been a way to use chromium-pepper-flash on FF for TW
I didn't check Leap, but will do
look for "freshplayerplugin"
"The main goal of this project is to get PPAPI (Pepper) Flash player working in Firefox. This wrapper implements some kind of adapter which will look like browser to PPAPI plugin and look like NPAPI plugin for browser."
Marguerite
On 26.10.2015 11:40, Marcus Meissner wrote:
Hi,
As package drops and additions should be mentioned on the -factory list ...
Adobe Flash Player has been dropped from both Leap 42.1 and Tumbleweed.
If you want to know why you are welcome to give a call to our legal aide Ciaran, whose phone number is in the drop request.
Sorry, I should have done that - but I dropped the ball ;( I won't argue with any reply, but I can tell you the facts: - adobe allows bundling flash-player only under very specific requirements - openSUSE no longer applies to these requirements as seen by the SUSE lawyers - their view is the only one that matters to me in that context Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/27/2015, 10:59 AM, Stephan Kulow wrote:
I won't argue with any reply, but I can tell you the facts:
- adobe allows bundling flash-player only under very specific requirements - openSUSE no longer applies to these requirements as seen by the SUSE lawyers - their view is the only one that matters to me in that context
The question really is what can be done to change their view? I.e. what exactly means "openSUSE no longer applies" -- what exactly has changed? Many webs, incl. youtube, are still unusable w/o flash. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-27 10:59, Stephan Kulow wrote:
- adobe allows bundling flash-player only under very specific requirements - openSUSE no longer applies to these requirements as seen by the SUSE lawyers - their view is the only one that matters to me in that context
I suppose this will also affect 11.4, 13.1, and 13.2? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Oct 26, Marcus Meissner wrote:
Adobe Flash Player has been dropped from both Leap 42.1 and Tumbleweed.
The pkg is now available from the packman "Extras" repository. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello Olaf On Oct 28 07:47 Olaf Hering wrote (excerpt):
On Mon, Oct 26, Marcus Meissner wrote:
Adobe Flash Player has been dropped from both Leap 42.1 and Tumbleweed.
The pkg is now available from the packman "Extras" repository.
Could you add this information to https://en.opensuse.org/Adobe_Flash_Player so that this information is available for all openSUSE users? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.10.2015 um 12:06 schrieb Johannes Meixner:
Could you add this information to https://en.opensuse.org/Adobe_Flash_Player so that this information is available for all openSUSE users?
No, because login fails. Fehler: Umleitungsfehler Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 28, 2015 at 2:54 PM, Olaf Hering
Am 28.10.2015 um 12:06 schrieb Johannes Meixner:
Could you add this information to https://en.opensuse.org/Adobe_Flash_Player so that this information is available for all openSUSE users?
No, because login fails.
Fehler: Umleitungsfehler Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.
Happens to me on regular basis. Removing cookies from novell, suse and microfocus usually helps. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Mittwoch, 28. Oktober 2015 schrieb Olaf Hering:
Am 28.10.2015 um 12:06 schrieb Johannes Meixner:
Could you add this information to https://en.opensuse.org/Adobe_Flash_Player so that this information is available for all openSUSE users?
No, because login fails.
Fehler: Umleitungsfehler Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.
I've seen this more than once (mostly in bugzilla), and I have a *guess* why it happens. Usually I see this message when I'm logged in since several hours. It seems there are different "opinions" about the login lifetime at various places. The login check (when loading a wiki/bugzilla page) thinks the login expired, so you get redirected to the login page - which thinks you are still logged in and then forwards you to the page you came from, which does the login check again and thinks your login expired and therefore redirects you to the login page, ... Germans, sing "Ein Loch ist im Eimer, Karl-Otto, Karl-Otto, ..." now! For everybody who doesn't understand that: that's a funny song which is basically the long version of "GOTO 1" ;-) BTW: https://login.microfocus.com tells me the session is valid for 540 minutes = 9 hours. Regards, Christian Boltz -- Please, if you use any of my code in your giant list of bad coding practices, feel free to not attribute me. :) [Seth Arnold in apparmor] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Christian Boltz composed on 2015-10-28 18:16 (UTC+0100):
No, because login fails.
Fehler: Umleitungsfehler Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.
I've seen this more than once (mostly in bugzilla), and I have a *guess* why it happens.
Usually I see this message when I'm logged in since several hours.
It seems there are different "opinions" about the login lifetime at various places. The login check (when loading a wiki/bugzilla page) thinks the login expired, so you get redirected to the login page - which thinks you are still logged in and then forwards you to the page you came from, which does the login check again and thinks your login expired and therefore redirects you to the login page, ...
Germans, sing "Ein Loch ist im Eimer, Karl-Otto, Karl-Otto, ..." now! For everybody who doesn't understand that: that's a funny song which is basically the long version of "GOTO 1" ;-)
BTW: https://login.microfocus.com tells me the session is valid for 540 minutes = 9 hours.
I wish it would reset on each load of a new URL, instead of arbitrarily asking to login yet again after that period expires and something in an open page is clicked on. No other bugzilla bug tracker I've ever used timeouts before the browser session expires, if that soon. Some don't expire unless the browser version or IP changes since login. After all, it's not a financial institution or home for proprietary information. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-28 18:53, Felix Miata wrote:
I wish it would reset on each load of a new URL, instead of arbitrarily asking to login yet again after that period expires and something in an open page is clicked on. No other bugzilla bug tracker I've ever used timeouts before the browser session expires, if that soon. Some don't expire unless the browser version or IP changes since login. After all, it's not a financial institution or home for proprietary information.
Can't be done. openSUSE uses the same identification backend for all the users and services, not just bugzilla. Bugzilla has to query this server for validation of the user. Some of the services require little security, but others do. The advantage is that it is very difficult to crack. Some openSUSE sites have been cracked, but the password/email data they got was faked, so no damage to anybody. Another advantage is that you login in one of the sites, and you are automatically recognized in the rest. Yes, it has imperfections. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (42)
-
Andreas Schwab
-
Andrei Borzenkov
-
Benjamin Denisart
-
Bjørn Lie
-
Carlos E. R.
-
Carlos E. R.
-
Christian Boltz
-
Claudio Freire
-
Daniel Fuhrmann
-
Dominique Leuenberger / DimStar
-
Felix Miata
-
Frederic Crozat
-
James Mason
-
Jan Engelhardt
-
Jimmy Berry
-
Jiri Slaby
-
Johannes Kastl
-
Johannes Meixner
-
Ken Schneider - Factory
-
Knurpht - Gertjan Lettink
-
Ludwig Nussel
-
Marcus Meissner
-
Marguerite Su
-
Martin Schlander
-
Mathias Homann
-
Olaf Hering
-
Oliver Kurz
-
Patrick Shanahan
-
Raymond Wooninck
-
Richard Brown
-
Robby Engelmann
-
Robert Kaiser
-
Robert Munteanu
-
Stefan Seyfried
-
Stefan Zimmer
-
Stefan Zimmer
-
Stephan Kulow
-
Uzair Shamim
-
Uzair Shamim
-
Vahis
-
Werner Flamme
-
Wolfgang Rosenauer