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

...

...

...

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

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

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

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

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

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

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 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

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

-----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

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)

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)

"Carlos E. R." writes:

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

-----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

Jiri Slaby writes:

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

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. -- 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

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 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 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)

Hello, On Oct 27 14:56 Carlos E. R. wrote (excerpt):

The link is:

http://get.adobe.com/flashplayer/otherversions/

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-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 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 Tue, Oct 27, 2015 at 11:40 AM, Mathias Homann wrote:

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

Отправлено с 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

-----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

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

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

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

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)

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

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 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

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

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

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? -- 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 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. -- 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

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 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)

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)

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, 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

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

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 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

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

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)

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 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

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 profile shm-install { #include #include #include #include capability audit_write, capability chown, capability dac_override, capability fowner, capability fsetid, capability mknod, capability net_admin, capability setgid, capability setuid, capability sys_admin, capability sys_chroot, capability sys_resource, network inet dgram, / r, /bin/* rix, /bin/bash ix, /bin/rpm rix, /dev/ r, /dev/shm/ r, /dev/shm/install/ r, /dev/shm/install/*/ rwlk, # includes creating the directory /dev/shm/install/home/ /dev/shm/install/bin/** mrwlk, /dev/shm/install/bin/rpm rix, /dev/shm/install/boot/** mrwlk, /dev/shm/install/dev/lp0 w, /dev/shm/install/dev/lp1 w, /dev/shm/install/dev/lp2 w, /dev/shm/install/dev/lp3 w, /dev/shm/install/dev/null rw, /dev/shm/install/dev/stderr w, /dev/shm/install/etc/** mrwlk, /dev/shm/install/etc/init.d/boot.apparmor rix, /dev/shm/install/lib/** mrwlk, /dev/shm/install/lib64/** mrwlk, /dev/shm/install/mnt/** mrwlk, /dev/shm/install/opt/** mrwlk, /dev/shm/install/root/** mrwlk, /dev/shm/install/run/cups/ w, /dev/shm/install/run/cups/certs/ w, /dev/shm/install/run/mcelog/ w, /dev/shm/install/run/nfs/ w, /dev/shm/install/run/nscd/ w, /dev/shm/install/run/openvpn/ rw, /dev/shm/install/run/regenerate-initrd/ rw, /dev/shm/install/run/regenerate-initrd/all w, /dev/shm/install/run/screens/ rw, /dev/shm/install/run/tuned/ w, /dev/shm/install/run/uscreens/ rw, /dev/shm/install/run/utmp w, /dev/shm/install/sbin/** mrwlk, /dev/shm/install/sbin/ldconfig rix, /dev/shm/install/selinux/** mrwlk, /dev/shm/install/srv/** mrwlk, /dev/shm/install/tmp/** mrwlk, /dev/shm/install/usr/** mrwlk, /dev/shm/install/usr/lib/ca-certificates/update.d/* rix, /dev/shm/install/usr/lib/man-db/mandb rix, /dev/shm/install/usr/lib/plymouth/plymouth-update-initrd rix, /dev/shm/install/usr/lib/smartmontools/generate_smartd_opts rix, /dev/shm/install/usr/lib/systemd/systemd-random-seed rix, /dev/shm/install/usr/lib/words/update rix, /dev/shm/install/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh rix, /dev/shm/install/usr/share/grub2/themes/openSUSE/activate-theme rix, /dev/shm/install/usr/{s,}bin/* rix, /dev/shm/install/var/** mrwlk, /dev/shm/install/var/adm/update-scripts/* rix, /dev/shm/install/var/adm/update-scripts/posttrans** rix, /dev/shm/install/{s,}bin/* rix, /dev/tty rw, /etc/lesskey.bin r, /etc/magic r, /etc/resolv.conf r, /etc/rpm/ r, /etc/rpm/** r, /etc/sysconfig/storage r, /etc/zypp/systemCheck.d/ r, /etc/zypp/zypp.conf r, /etc/zypp/zypper.conf r, /home/*/.inputrc r, /mnt/ r, /mnt/suse/ r, /mnt/suse/** r, /proc/*/cmdline r, /proc/filesystems r, /proc/meminfo r, /proc/sys/kernel/random/uuid r, /root/ r, /root/.lesshst r, /sys/ r, /sys/**/ r, /sys/devices/** r, /tmp/less.* rw, /usr/bin/cp rix, /usr/bin/diff rix, /usr/bin/file rix, /usr/bin/find rix, /usr/bin/grep rix, /usr/bin/less rix, /usr/bin/lessopen.sh rix, /usr/bin/mktemp rix, /usr/bin/perl ix, /usr/bin/repo2solv.sh rix, /usr/bin/rm rix, /usr/bin/rpmdb2solv rix, /usr/bin/rpms2solv rix, /usr/lib{,32,64}/** mr, /usr/share/misc/magic.mgc r, /usr/share/rpm/** r, /usr/share/terminfo/ r, /usr/share/zypper/ r, /usr/share/zypper/** r, /var/log/zypper.log w, /var/run/nscd/* r, /var/tmp/ r, /var/tmp/TmpDir.*/ rw, /var/tmp/TmpFile.* rw, /var/tmp/zypp.** rw, } Now load the profile and install openSUSE into /dev/shm/install/ # rcapparmor reload # mkdir /dev/shm/install # aa-exec -p shm-install -- zypper --root /dev/shm/install/ ar -G /mnt/suse/ dvd-image # change as needed # aa-exec -p shm-install -- zypper --root /dev/shm/install/ in --download-as-needed patterns-openSUSE-kde_utilities patterns-openSUSE-multimedia patterns-openSUSE-office_opt patterns-openSUSE-kde_plasma patterns-openSUSE-yast2_basis patterns-openSUSE-non_oss patterns-openSUSE-enhanced_base patterns-openSUSE-games patterns-openSUSE-fonts_opt patterns-openSUSE-non_oss_opt patterns-openSUSE-base patterns-openSUSE-kde_multimedia patterns-openSUSE-x11 patterns-openSUSE-kde_utilities_opt patterns-openSUSE-yast2_install_wf patterns-openSUSE-multimedia_opt patterns-openSUSE-kde_imaging patterns-openSUSE-sw_management_kde patterns-openSUSE-fonts patterns-openSUSE-imaging patterns-openSUSE-kde_internet patterns-openSUSE-apparmor_opt patterns-openSUSE-x11_opt patterns-openSUSE-sw_management patterns-openSUSE-apparmor patterns-openSUSE-kde_yast patterns-openSUSE-enhanced_base_opt patterns-openSUSE-imaging_opt patterns-openSUSE-kde_games patterns-openSUSE-minimal_base patterns-openSUSE-kde_office patterns-openSUSE-kde patterns-openSUSE-laptop patterns-openSUSE-office (that's basically a default install with KDE) Note that with --root /dev/shm/install/, zypper still uses some parts of the main system (for example less to display notifications at the end, and it also writes to /var/log/zypper.log), so the profile contains some permissions outside the given --root. Doing a similar test from an installation system will probably give you a more clean profile, but basically with the same result: A default tumbleweed install with KDE does not touch anything inside /home :-) 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 ;-) /dev/null and /dev/stderr make more sense and are probably used by various %post scripts. BTW: Is it expected that the GPG signature check fails for every package when installing with --root into an empty directory? I had to use "zypper ar -G" to disable the checks, but that's not something I like. Some final notes: - if you want to re-create this profile from scratch, note that you'll get *lots of* entries in your audit.log. It might even rotate away faster than you can use aa-genprof or aa-logprof, so you also need to check the rotated-away logs. - installing to /dev/shm/install obviously needs some ;-) RAM Regards, Christian Boltz -- In the beginning was the word, and the word was content-type: text/plain -- 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, 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

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

* 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/ -- (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

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... --

"Carlos E. R." writes:

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 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

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

On Mon, Oct 26, 2015 at 11:04 AM, Robert Kaiser wrote:

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 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 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

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

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

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)