[DNG] KUserFeedback
Hi, while reading the latest edition of the PCLinuxOS Magazine, I've found this interesting article about KUserFeedback at https://pclosmag.com/html/Issues/202109/page09.html which relevant parts I copy here for ease of discussion: " Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's implementation of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it without any collateral effects to the system, while other users reported that doing the same in other distros (like Debian 11) results in the complete removal of KDE Plasma! Why force such an implementation, if, as KDE's developers say, it is just an innocuous, privacy-respecting measure? Coincidence or not, in the past years many popular Linux distributions started rolling out optional telemetry. Then it was the time of computer programs: news broke out in May regarding Audacity, a popular audio editing app, which announced it was starting the use of telemetry. The move was finally pushed back after users revolted against it. But in Plasma's case, it is not just an app or a single distro, but an entire desktop environment, employed in several Linux distributions, that is being shipped with telemetry. While many point out that the data collection is by opt-in and entirely anonymous, others have found that, even if you don't activate telemetry, data is still collected, using computer resources, registering "apps and boot, number of times used and duration in /home/user/telemetry folder." As such, they argue that, because of the way Linux permissions work, other programs could have access to these log files. KUserFeedback's FAQs page confirms this: 'KUserFeedback is designed to be compliant with KDE Telemetry Policy, which forbids the usage of unique identification. If you are using KUserFeedback outside of the scope of that policy, it's of course possible to add a custom data source generating and transmitting a unique id.' Not being an expert on such matters, it is anyway a little strange the step taken by KDE and the way it is being implemented by most mainstream distros, as if there was a certain consternation about it. To better understand the picture, let us give a look at the organization that maintains the Plasma desktop." What possible solutions are there to avoid this user data hoarding and their abuse? Simple workarounds that I can think off: 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective as most user will not care to do so) 1a) allow removal of KUserFeedback by modifying deb deps and don't install by default unless the way data is collected is changed so that data are collected only if opted in 2) if the user opted out make /home/user/telemetry a tmpfs so that data stored are forgotten at reboot (easy but not very effective as data could still be abused in the meanwhile) 3) if the user opted out create some kind of /dev/null folder (I suspect that such thing doesn't exist yet) to delete the data in realtime 4) if the user opted out run cron jobs or other autostart scripts to periodically (boot, login, logout, hourly etc) delete this data Comments and better ideas are welcome. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
Hi! Anno domini 2021 Sun, 5 Sep 09:52:11 +0200 tito via Dng scripsit: > Hi, > while reading the latest edition of the PCLinuxOS Magazine, > I've found this interesting article about KUserFeedback > at https://pclosmag.com/html/Issues/202109/page09.html > which relevant parts I copy here for ease of discussion: > > " Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's > implementation > of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it > without any > collateral effects to the system, while other users reported that doing the > same in other > distros (like Debian 11) results in the complete removal of KDE Plasma! Why > force such > an implementation, if, as KDE's developers say, it is just an innocuous, > privacy-respecting > measure? > > Coincidence or not, in the past years many popular Linux distributions > started rolling out > optional telemetry. Then it was the time of computer programs: news broke out > in May > regarding Audacity, a popular audio editing app, which announced it was > starting the > use of telemetry. The move was finally pushed back after users revolted > against it. > > But in Plasma's case, it is not just an app or a single distro, but an entire > desktop > environment, employed in several Linux distributions, that is being shipped > with > telemetry. While many point out that the data collection is by opt-in and > entirely > anonymous, others have found that, even if you don't activate telemetry, data > is > still collected, using computer resources, registering "apps and boot, number > of > times used and duration in /home/user/telemetry folder." As such, they argue > that, > because of the way Linux permissions work, other programs could have access > to these log files. KUserFeedback's FAQs page confirms this: > > 'KUserFeedback is designed to be compliant with KDE Telemetry Policy, which > forbids > the usage of unique identification. If you are using KUserFeedback outside of > the > scope of that policy, it's of course possible to add a custom data source > generating > and transmitting a unique id.' > > Not being an expert on such matters, it is anyway a little strange the step > taken by > KDE and the way it is being implemented by most mainstream distros, as if > there > was a certain consternation about it. To better understand the picture, let > us give > a look at the organization that maintains the Plasma desktop." > > What possible solutions are there to avoid this user data hoarding and their > abuse? > > Simple workarounds that I can think off: > > 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective > as most user will not care to do so) > > 1a) allow removal of KUserFeedback by modifying deb deps and don't install > by default unless the way data is collected is changed so that data > are collected only if opted in > > 2) if the user opted out make /home/user/telemetry a tmpfs so that data stored > are forgotten at reboot (easy but not very effective as data could still > be >abused in the meanwhile) > > 3) if the user opted out create some kind of /dev/null folder (I suspect that > such > thing doesn't exist yet) to delete the data in realtime > > 4) if the user opted out run cron jobs or other autostart scripts to > periodically > (boot, login, logout, hourly etc) delete this data > > Comments and better ideas are welcome. Don't think a lot of people here use KDE4 :) Anyway, e.g. "audacity" has added "telemetry" and "lawful inspection" a while ago and was promptly forked https://www.theregister.com/2021/07/06/audacity_fork/ . Unpleasently there is still audacity in the devuan/debian repository, so keep an eye open on the new spyware. nik > > Ciao, > Tito > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
<--snip--> > Comments and better ideas are welcome. Apparmor publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 08:54:14 + g4sra via Dng wrote: > <--snip--> > > Comments and better ideas are welcome. > > Apparmor Hi, the cure is worse than the disease ;-) Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday, September 5th, 2021 at 11:15 AM, tito wrote: > On Sun, 05 Sep 2021 08:54:14 + > g4sra via Dng dng@lists.dyne.org wrote: > > <--snip--> > > > Comments and better ideas are welcome. > > Apparmor > Hi, > the cure is worse than the disease ;-) How is Apparmor abusive ? publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 10:18:15 + g4sra via Dng wrote: > On Sunday, September 5th, 2021 at 11:15 AM, tito wrote: > > On Sun, 05 Sep 2021 08:54:14 + > > g4sra via Dng dng@lists.dyne.org wrote: > > > <--snip--> > > > > Comments and better ideas are welcome. > > > Apparmor > > Hi, > > the cure is worse than the disease ;-) > How is Apparmor abusive ? > Hi, I'm not very fond of apparmor for various reasons: 1) I experienced unexpected behavior of programs silently failing to do something (log, run, etc) because the apparmor profile was wrong/bugged 2) unless you study every code path in the program you want to supervise the profiles used will not be safe but nobody really cares (e.g. maintainer adds a profile that works with the default setup of the distro (if it really works)) 3) if you use a customized setup of services or other programs it is highly probable that the profiles will not work for you Summary: apparmor gets in the way of doing stuff and in the end adds just one more software layer with a million code lines and the inevitable programming errors, so in my humble opinion it just adds complexity (bad!) with no guarantee of improving security (not so good!) and makes linux more windows-like (worse!!). Addendum: Quis custodiet ipsos custodes? What will be the next evolutionary step, will we need a new layer that secures apparmor? My Solution: To avoid all of this trouble and reduce complexity I pin -1 apparmor in apt preferences, purge it and everything related and disable it on the kernel command line with apparmor=0 and everything is smooth, understandable and reliable again as it has been "in saecula saeculorum". Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 5 Sep 2021 09:59:09 +0200 "Dr. Nikolaus Klepp via Dng" wrote: > Hi! > > Anno domini 2021 Sun, 5 Sep 09:52:11 +0200 > tito via Dng scripsit: > > Hi, > > while reading the latest edition of the PCLinuxOS Magazine, > > I've found this interesting article about KUserFeedback > > at https://pclosmag.com/html/Issues/202109/page09.html > > which relevant parts I copy here for ease of discussion: > > > > " Recently, there was a debate on the PCLinuxOS forum about KDE Plasma's > > implementation > > of telemetry through KUserFeedback. While in PCLinuxOS, we can remove it > > without any > > collateral effects to the system, while other users reported that doing > > the same in other > > distros (like Debian 11) results in the complete removal of KDE Plasma! > > Why force such > > an implementation, if, as KDE's developers say, it is just an innocuous, > > privacy-respecting > > measure? > > > > Coincidence or not, in the past years many popular Linux distributions > > started rolling out > > optional telemetry. Then it was the time of computer programs: news broke > > out in May > > regarding Audacity, a popular audio editing app, which announced it was > > starting the > > use of telemetry. The move was finally pushed back after users revolted > > against it. > > > > But in Plasma's case, it is not just an app or a single distro, but an > > entire desktop > > environment, employed in several Linux distributions, that is being shipped > > with > > telemetry. While many point out that the data collection is by opt-in and > > entirely > > anonymous, others have found that, even if you don't activate telemetry, > > data is > > still collected, using computer resources, registering "apps and boot, > > number of > > times used and duration in /home/user/telemetry folder." As such, they > > argue that, > > because of the way Linux permissions work, other programs could have access > > to these log files. KUserFeedback's FAQs page confirms this: > > > > 'KUserFeedback is designed to be compliant with KDE Telemetry Policy, which > > forbids > > the usage of unique identification. If you are using KUserFeedback outside > > of the > > scope of that policy, it's of course possible to add a custom data source > > generating > > and transmitting a unique id.' > > > > Not being an expert on such matters, it is anyway a little strange the step > > taken by > > KDE and the way it is being implemented by most mainstream distros, as if > > there > > was a certain consternation about it. To better understand the picture, let > > us give > > a look at the organization that maintains the Plasma desktop." > > > > What possible solutions are there to avoid this user data hoarding and > > their > > abuse? > > > > Simple workarounds that I can think off: > > > > 1) allow removal of KUserFeedback by modifying deb deps (rather ineffective > > as most user will not care to do so) > > > > 1a) allow removal of KUserFeedback by modifying deb deps and don't install > > by default unless the way data is collected is changed so that data > > are collected only if opted in > > > > 2) if the user opted out make /home/user/telemetry a tmpfs so that data > > stored > > are forgotten at reboot (easy but not very effective as data could > > still be > >abused in the meanwhile) > > > > 3) if the user opted out create some kind of /dev/null folder (I suspect > > that such > > thing doesn't exist yet) to delete the data in realtime > > > > 4) if the user opted out run cron jobs or other autostart scripts to > > periodically > > (boot, login, logout, hourly etc) delete this data > > > > Comments and better ideas are welcome. > > Don't think a lot of people here use KDE4 :) Hi, I do, that's a lot to me! .and we ship it in the repos that is a enough of a reason to care about it. cura ut valeas > Anyway, e.g. "audacity" has added "telemetry" and "lawful inspection" a while > ago and was promptly forked > https://www.theregister.com/2021/07/06/audacity_fork/ . Unpleasently there is > still audacity in the devuan/debian repository, so keep an eye open on the > new spyware. > > nik > > > > > Ciao, > > Tito > > > > > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday, September 5th, 2021 at 11:54 AM, tito via Dng wrote: > On Sun, 05 Sep 2021 10:18:15 + > g4sra via Dng dng@lists.dyne.org wrote: > > On Sunday, September 5th, 2021 at 11:15 AM, tito farmat...@tiscali.it wrote: > > > On Sun, 05 Sep 2021 08:54:14 + > > > g4sra via Dng dng@lists.dyne.org wrote: > > > > <--snip--> > > > > > Comments and better ideas are welcome. > > > > Apparmor > > > > Hi, > > > > the cure is worse than the disease ;-) > > > > How is Apparmor abusive ? > Hi, > > I'm not very fond of apparmor for various reasons: > 1. I experienced unexpected behavior of programs > silently failing to do something (log, run, etc > because the apparmor profile was wrong/bugged > 2. unless you study every code path in the program you want to > supervise the profiles used will not be safe but nobody really cares > (e.g. maintainer adds a profile that works with the default setup > of the distro (if it really works)) > 3. if you use a customized setup of services or other programs > it is highly probable that the profiles will not work for you > > Summary: > > apparmor gets in the way of doing stuff and > in the end adds just one more software layer > with a million code lines and the inevitable > programming errors, so in my humble opinion > it just adds complexity (bad!) with no guarantee of improving > security (not so good!) and makes linux more > windows-like (worse!!). > > Addendum: > > Quis custodiet ipsos custodes? > > What will be the next evolutionary step, will we need > a new layer that secures apparmor? > > My Solution: > > To avoid all of this trouble and reduce complexity I pin -1 > apparmor in apt preferences, purge it and everything related > and disable it on the kernel command line with apparmor=0 > and everything is smooth, understandable and reliable again > as it has been "in saecula saeculorum". > > Ciao, > > Tito > So to summarise... The answer to my question 'What is abusive about Apparmor ?' is "nothing". You don't like it because you find it overly complicated to configure. Better throw overly complicated to configure KDE4 out (and Xorg, and ALSA, and...) with the bathwater as well then, and then KUserFeedback becomes a non-issue. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday 05 September 2021 at 12:54:01, tito via Dng wrote: > On Sun, 05 Sep 2021 10:18:15 + g4sra wrote: > > > > How is Apparmor abusive ? > > I'm not very fond of apparmor for various reasons: > > 1) I experienced unexpected behavior of programs > silently failing to do something (log, run, etc) > because the apparmor profile was wrong/bugged > > 2) unless you study every code path in the program you want to > supervise the profiles used will not be safe but nobody really cares > (e.g. maintainer adds a profile that works with the default setup > of the distro (if it really works)) > > 3) if you use a customized setup of services or other programs > it is highly probable that the profiles will not work for you So, a bad configuration doesn't work as you would like. No surprise there, really. > Summary: >apparmor gets in the way of doing stuff... You can say the same about network firewalls (or almost any security measure, in fact). Security is seldom aligned with convenience. However, just as many people would not want to operate systems without a network firewall, and are prepared to configure it correctly for their needs, I think apparmor has a valuable place in enforcing security within one system; the price is that the system admin has to tell it to do the right job. Antony. -- Was ist braun, liegt ins Gras, und raucht? Ein Kaminchen... Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
> 3) if the user opted out create some kind of /dev/null folder (I suspect that > such > thing doesn't exist yet) to delete the data in realtime Is the data saved into the telemetry folder before being transmitted anywhere? Can you just delete the folder and recreate it as a symlink to /dev/null? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 5 Sep 2021 13:25:58 +0200 Antony Stone wrote: > On Sunday 05 September 2021 at 12:54:01, tito via Dng wrote: > > > On Sun, 05 Sep 2021 10:18:15 + g4sra wrote: > > > > > > How is Apparmor abusive ? > > > > I'm not very fond of apparmor for various reasons: > > > > 1) I experienced unexpected behavior of programs > > silently failing to do something (log, run, etc) > > because the apparmor profile was wrong/bugged > > > > 2) unless you study every code path in the program you want to > > supervise the profiles used will not be safe but nobody really cares > > (e.g. maintainer adds a profile that works with the default setup > > of the distro (if it really works)) > > > > 3) if you use a customized setup of services or other programs > > it is highly probable that the profiles will not work for you > > So, a bad configuration doesn't work as you would like. No surprise there, > really. > > Summary: > >apparmor gets in the way of doing stuff... > > You can say the same about network firewalls (or almost any security measure, > in fact). Security is seldom aligned with convenience. Hi, Yes and this makes security lucrative and unquestionable. > However, just as many people would not want to operate systems without a > network firewall, and are prepared to configure it correctly for their needs, > I All ports by default are in CLOSED state so the default is safe unless you want to run a service on a port and control or filter access to that service through this port. You don't need a watchdog by default to check if the ports are closed. This is security by design. > think apparmor has a valuable place in enforcing security within one system; > the price is that the system admin has to tell it to do the right job. The "right job" as I understand it is to let program apparmor tell program xyz to do what it is allowed to do, which program xyz already knows as it is written in his code. Could program xyz be subverted to do things that are not written in his code or are unwanted then better fix xyz rather than add more code as watchdog. Ciao, Tito > > Antony. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sunday 05 September 2021 at 14:46:34, tito via Dng wrote: > On Sun, 5 Sep 2021 13:25:58 +0200 Antony Stone wrote: > > > > You can say the same about network firewalls (or almost any security > > measure, in fact). Security is seldom aligned with convenience. > > Hi, > Yes and this makes security lucrative and unquestionable. Neither of those correlate with "not a good idea". > Could program xyz be subverted to do things that are not written in his > code or are unwanted then better fix xyz rather than add more code as > watchdog. Good idea to fix xyz (if you can), but also remember "security in depth". Antony. -- Most people have more than the average number of legs. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 11:07:59 + g4sra via Dng wrote: > On Sunday, September 5th, 2021 at 11:54 AM, tito via Dng > wrote: > > On Sun, 05 Sep 2021 10:18:15 + > > g4sra via Dng dng@lists.dyne.org wrote: > > > On Sunday, September 5th, 2021 at 11:15 AM, tito farmat...@tiscali.it > > > wrote: > > > > On Sun, 05 Sep 2021 08:54:14 + > > > > g4sra via Dng dng@lists.dyne.org wrote: > > > > > <--snip--> > > > > > > Comments and better ideas are welcome. > > > > > > Apparmor > > > > > Hi, > > > > > the cure is worse than the disease ;-) > > > > > How is Apparmor abusive ? > > Hi, > > > > > I'm not very fond of apparmor for various reasons: > > 1. I experienced unexpected behavior of programs > > > silently failing to do something (log, run, etc > > > because the apparmor profile was wrong/bugged > > 2. unless you study every code path in the program you want to > > > supervise the profiles used will not be safe but nobody really cares > > > (e.g. maintainer adds a profile that works with the default setup > > > of the distro (if it really works)) > > 3. if you use a customized setup of services or other programs > > > it is highly probable that the profiles will not work for you > > > > > Summary: > > > > > apparmor gets in the way of doing stuff and > > > in the end adds just one more software layer > > > with a million code lines and the inevitable > > > programming errors, so in my humble opinion > > > it just adds complexity (bad!) with no guarantee of improving > > > security (not so good!) and makes linux more > > > windows-like (worse!!). > > > > > Addendum: > > > > > Quis custodiet ipsos custodes? > > > > > What will be the next evolutionary step, will we need > > > a new layer that secures apparmor? > > > > > My Solution: > > > > > To avoid all of this trouble and reduce complexity I pin -1 > > > apparmor in apt preferences, purge it and everything related > > > and disable it on the kernel command line with apparmor=0 > > > and everything is smooth, understandable and reliable again > > > as it has been "in saecula saeculorum". > > > > > Ciao, > > > > > Tito > > > > So to summarise... > The answer to my question 'What is abusive about Apparmor ?' is "nothing". The concept is abusive: 1) it is not KISS 2) it does not fix the underlying issues if there are any 3) who watches the watchdog? Ciao, Tito > > You don't like it because you find it overly complicated to configure. > Better throw overly complicated to configure KDE4 out (and Xorg, and ALSA, > and...) with the bathwater as well then, and then KUserFeedback becomes a > non-issue. > > I find them easier to configure than apparmor despite the fact they want to start to spy on me. > > > > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 5 Sep 2021 22:40:23 +1000 wirelessduck--- via Dng wrote: > > > 3) if the user opted out create some kind of /dev/null folder (I suspect > > that such > > thing doesn't exist yet) to delete the data in realtime > > Is the data saved into the telemetry folder before being transmitted > anywhere? Can you just delete the folder and recreate it as a symlink to > /dev/null? Hi, They say it is not transmitted by them unless you opt-in but it is stored and other applications with the same user permissions could read it and send it if they want to. So periodically deleting the data could be a mitigation but is sub-optimal. You cannot link a directory to /dev/null, only files. To create a directory equivalent to /dev/null you need something like: https://github.com/abbbi/nullfsvfs nullfs a virtual file system that behaves like /dev/null It can handle regular file operations like mkdir/rmdir/ln but writing to files does not store any data. The file size is however saved, so reading from the files behaves like reading from /dev/zero with a fixed size. Writing and reading is basically an NOOP, so it can be used for performance testing with applications that require directory structures. Implemented as kernel module, instead of using FUSE, there is absolutely no overhead for copying application data from user to kernel space while performing write or read operations. This one looks really good to me as the project seems to be active and has dkms support. I think I will test it as it comes handy to solve this and similar cases of data hoarding by sending the data directly into oblivion. Will add it to my private repo. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Video cards on Linux (was Re: Information request re: wayland)
On 9/3/21 06:24, o1bigtenor wrote: How did you get your 1050 Ti working under nouveau? How many monitors/sizes are you driving off of it? This is the card that I'm fighting!! Trying to drive 2 - 1920x1080 and 1 - 4k. Its the 4k monitor that seems to cause the issues!! (Please pretty please - - - - do you have any ideas/suggestions!) Hopefully this pastebin helps. I didn't want to attach it to the list because this much text becomes impossible to read. Let me know if you need more info. I don't really know what else to include here. Oh, I'm not sure why 'nouveau' is blacklisted -- I thought 'nouveau' was another name for the freeware build of the proprietary Nvidia driver but maybe I don't understand correctly. https://pastebin.com/NvUtaCnQ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Information request re: wayland
On 9/4/21 03:17, Steve Litt wrote: Bruce Perens via Dng said on Fri, 3 Sep 2021 10:30:06 -0700 Unfortunately there isn't really a good display solution for Linux that does not make use of "direct rendering", in which user-mode code talks directly to the display hardware I'm reminded of writing to the RAM following B800 on DOS :-). Heh.. I seem to recall B000 was available for that as well if you had no monochrome monitor attached. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 2021-09-05 at 12:54 +0200, tito via Dng wrote: > Hi, > I'm not very fond of apparmor for various reasons: > > 1) I experienced unexpected behavior of programs > silently failing to do something (log, run, etc) > because the apparmor profile was wrong/bugged I experienced the same, as my first introduction to AppArmor, and a couple times more before I did the same as you and purged it. > > 2) unless you study every code path in the program you want to > supervise the profiles used will not be safe but nobody really > cares > (e.g. maintainer adds a profile that works with the default > setup > of the distro (if it really works)) This is a great point and probably the biggest reason I remain unsure about it, combined with the level of permissions it controls, it's like giving another root-level program access to every bit of processing that happens. Yes all programs have code that need to be understood to be trusted, but a program with root-level authority that polices all other programsI need to understand that program a lot better, before trusting it, than I do basically any other program. Maybe there are flaws in that thinking, but unless I misunderstand the level of permission and control AppArmor has, I'm right to be weary of it. Also, the fact that it comes by default, and is enabled by default, and has those permissions and capabilities, to me, that's the kind of program that is likely to be exploited in the future, assuming it's not exploited now and that the dev's or the project are exploitable one way or another. The fact that it has such permissions and is enabled by default, and that it was introduced recently, all of those things justify suspicion as far as I'm concerned. To my unprofessional but suspicious eyes, it reminds me of systemd. Maybe we're wrong, but until we take the time to look at and understand every line of code, and get to know the project, it seems far safer to rely on things like firewalls and other trusted security tools. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Firefox, sudo and apulse (was Re: Steam, Mumble, Valheim, Alsa and shared audio)
On September 4, 2021 4:40:34 AM CDT, g4sra via Dng wrote:
:: On Tuesday, August 31st, 2021 at 7:41 PM, hal wrote
:: > On 8/31/21 11:02, g4sra via Dng wrote:
:: >
:: > > > ctl.!default {
:: > > > type hw
:: > > > card 0
:: > > > }
:: > > >
::
:: > > > Check to make sure you do not have a ~/.asoundrc overriding
/etc/asound.conf
:: > Good thought, and have checked this. Especially relevant with the
multi-user situation. I will check on the other enlightening ALSA suggestions
you have made.
:: >
:: > > get user_one's cookie:
:: > > user_one# xauth -n list localhost/unix:0
:: > > localhost/unix:0 MIT-MAGIC-COOKIE-1 83c12a394ac0c5afe1fee0a973b9e49g
:: > > then give the cookie to user_two:
:: > > user_two# xauth add localhost/unix:0 MIT-MAGIC-COOKIE-1
83c12a394ac0c5afe1fee0a973b9e49g
:: > > now 'user_two' can access the GUI (you may need to set DISPLAY):
:: > > user_two# DISPLAY=:0 /usr/bin/apulse /home/apps/firefox/firefox
-ProfileManager
:: > Thank you for this! I have always used 'xhost +' and drop TCP 6000 (eth0)
on the host firewall (on my "single-user" workstation anyway). I've tried to
find more secure ways to share the X cookie but for one reason or another, they
never worked out. I will try this!
::
:: Hi Hal,
::
:: I replied off-list, it just occurred to me it may have gone into your spam
box.
g4sra,
yes I did see your reply thank you for that. I am not good at managing my time
and have been swamped the last few days. you noticed some very good things then
maybe have been misconfigured on my system for quite some time. I will look
into these and post back on the list. thank you again!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
On Sun, 05 Sep 2021 08:00:51 -0600 Gabe Stanton via Dng wrote: > On Sun, 2021-09-05 at 12:54 +0200, tito via Dng wrote: > > Hi, > > I'm not very fond of apparmor for various reasons: > > > > 1) I experienced unexpected behavior of programs > > silently failing to do something (log, run, etc) > > because the apparmor profile was wrong/bugged > > I experienced the same, as my first introduction to AppArmor, and a > couple times more before I did the same as you and purged it. > > > > > 2) unless you study every code path in the program you want to > > supervise the profiles used will not be safe but nobody really > > cares > > (e.g. maintainer adds a profile that works with the default > > setup > > of the distro (if it really works)) > > This is a great point and probably the biggest reason I remain unsure > about it, combined with the level of permissions it controls, it's like > giving another root-level program access to every bit of processing > that happens. Yes all programs have code that need to be understood to > be trusted, but a program with root-level authority that polices all > other programsI need to understand that program a lot better, > before trusting it, than I do basically any other program. Maybe there > are flaws in that thinking, but unless I misunderstand the level of > permission and control AppArmor has, I'm right to be weary of it. > > Also, the fact that it comes by default, and is enabled by default, and > has those permissions and capabilities, to me, that's the kind of > program that is likely to be exploited in the future, assuming it's not > exploited now and that the dev's or the project are exploitable one way > or another. The fact that it has such permissions and is enabled by > default, and that it was introduced recently, all of those things > justify suspicion as far as I'm concerned. To my unprofessional but > suspicious eyes, it reminds me of systemd. > > Maybe we're wrong, but until we take the time to look at and understand > every line of code, and get to know the project, it seems far safer to > rely on things like firewalls and other trusted security tools. > > > Gabe > Hi, one stupid question that struck my mind right now could apparmor control itself? could you write an apparmor profile to limit what apparmor is doing? Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] AppArmor
On Sun, 2021-09-05 at 16:21 +0200, tito via Dng wrote: > Hi, > > one stupid question that struck my mind right now could > apparmor control itself? > could you write an apparmor profile to limit what apparmor > is doing? > > Ciao, > Tito Haha "Who polices the police?" "We do." - the police ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] License for the DNG created software guide --> Proposal: DNG Verbatim Libre License (upd)
al3xu5 said on Sat, 4 Sep 2021 17:36:45 +0200 >The discussion was not general, but specific about which license to >choose for a technical document written by an author (Steve). It was written by a lot more people than me. I simply curated all the contributions, and yes, I did write some of it myself. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] KUserFeedback
tito via Dng said on Sun, 5 Sep 2021 09:52:11 +0200 >Hi, >while reading the latest edition of the PCLinuxOS Magazine, >I've found this interesting article about KUserFeedback >at https://pclosmag.com/html/Issues/202109/page09.html >which relevant parts I copy here for ease of discussion: > >" Recently, there was a debate on the PCLinuxOS forum about KDE This is offtopic but I think it needs being said: I kicked all things KDE off my system for exactly the same reason I never let systemd on my system: A monolithic mess with gratuitious interconnections. The one difference between KDE and systemd is that at least KDE showed the good grace not to sabotage systems it was removed from. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Video cards on Linux (was Re: Information request re: wayland)
On Sun, Sep 5, 2021 at 8:52 AM hal wrote: > > > On 9/3/21 06:24, o1bigtenor wrote: > > > How did you get your 1050 Ti working under nouveau? > > How many monitors/sizes are you driving off of it? > > > > This is the card that I'm fighting!! > > Trying to drive 2 - 1920x1080 and 1 - 4k. > > Its the 4k monitor that seems to cause the issues!! > > > > (Please pretty please - - - - do you have any ideas/suggestions!) > > > Hopefully this pastebin helps. I didn't want to attach it to the list > because this much text becomes impossible to read. Let me know if you need > more info. I don't really know what else to include here. Oh, I'm not sure > why 'nouveau' is blacklisted -- I thought 'nouveau' was another name for > the freeware build of the proprietary Nvidia driver but maybe I don't > understand correctly. > > https://pastebin.com/NvUtaCnQ Hmmm - - - - the page shows for about 1/2 a second and then goes blank. tried clicking on the individual sections - - - still no joy. So I destroyed the pastebin cookies in the browser and purged the history file of anything to do with pastebin. Sorry - - - no can read. If you have houveau blacklisted then you pretty much are running the proprietary drivers. Are you driving a HDMI monitor? Thanks for the effort!! Regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
