Re: [DNG] [devuan-dev] [PATCH] (security) launcher: don't attempt to execute arbitrary binaries
Hello Enrico, On dt., gen. 07 2020, Enrico Weigelt wrote: What might supposed to be convenience functionality, poses a real-life security threat: A user can be tricked be tricked to download malicious code, unpack it with +x permissions (eg. via tar) and execute it by just clicking on the icton. In combination with other techniques (eg. homoglyphs), even more experienced users can be tricked "open" some supposedly harmless file type, while Thunar in fact executes a binary - with full user's privileges. (the same approach is one of the primary infection vectors used by thousands of malwares in Windows world, which already caused gigantic damages). Therefore introduce a new setting and only execute programs if explicitly enabled. That's great! Have you tried poking Thunar's developers into merging such a feature? This is where the developers would like such things: https://docs.xfce.org/xfce/thunar/bugs It'd really be the best place for a setting like this to land and benefit all Thunar users out there (which are not limited to Debian-like or even Linux, but also include the BSDs). Cheers! -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I wrote IBM
On dg., set. 29 2019, goli...@devuan.org wrote: On 2019-09-28 21:32, Steve Litt wrote: Hi all, I just wrote IBM asking them to reconsider systemd, given that IBM's business model is different from the old Red Hat's. [cut] I encourage all of you to write IBM. If I'm right and it helps, this would prevent future incompatibilities requiring significant increases in Devuan development effort, just to stay even. If I'm wrong, you lose a couple hours writing a letter. The web page for this letter writing campaign is as follows: Sorry Steve . . . I think this idea is naive, ill-advised and a tactical error that could have very real, unintended consequences. I do hope that neither Devuan nor s6 was mentioned in the letter that you sent. golinux +1. That's shy of stalking, does nothing productive to move forward your goal and, indeed, is counterproductive mid and long-term. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] why does mount expect NTFS?
Hey, On dg., ag. 11 2019, Hendrik Boom wrote: So I want to find out what's in /dev/sda4 on my hard drive. The computer has *never* had Windows on it. So I try to mount it, and am told: april:/farhome/hendrik# mount /dev/sda4 /test NTFS signature is missing. Failed to mount '/dev/sda4': Invalid argument The device '/dev/sda4' doesn't seem to have a valid NTFS. Just adding two things to what marc wrote: partition number 4 (sda4) is very often used as the extended partition in DOS partition tables. Regardless of its type, you should check the partition table; it will have the type byte set for each partition which says which use it's supposed to have, though it can actually not match the partition contents. I recall gparted and IIRC parted show this quite nicely. man parted was useful (at the very least the help command was). If it is an extended partition, then it's not supposed to be mountable, but you should check the 5th partition instead. Another fun thing that will work even if you are not using a DOS partition table is: just hexdump it! dd if=/dev/sda4 bs=1M count=1 | hd | less File systems usually have some kind of readable ASCII information at the beginning and amongst others an NTFS partition will be obvious there. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
Final update on this so it doesn't stay "open" forever: On dc., jul. 17 2019, Evilham wrote: On dc., jul. 17 2019, Bernard Rosset via Dng wrote: b) If not and this a confirmed defect, would not it be reasonable to remove said host from the pool until the maintainer can inspect what is going on and act on it? If we get more reports we totally will, so far everything is "looking good" and all tests pass, but maybe there is indeed something inherently spotty on the connection and that's what you are seeing; we'll see if with more data or more reports or when the maintainer takes a look something changes. Mirror maintainer confirmed very quickly that it was a hiccup they were dealing with by the time Bernard ran into it an ran his tests, so there is no need for further action regarding the particular mirror since, as we observed, it's back to normal. The connection-level monitoring should happen though :-). -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
On dc., jul. 17 2019, Bernard Rosset via Dng wrote: Thx Evilham for your answer. Glad it was not sinkholed ;o) Not at all :-). But maybe it'll be interesting to add simple monitoring at a connection level same way you ran your tests. I'll try to setup a thing in the next couple days. I was actually thinking about ways of involving the community, whose kind members already are actively participating in mirrors & such, in a distributed monitoring array. While heavy checks might be run on more central, tighly-controlled components, availability checks could be run from anyone's scheduled tasks manager, and might be aggregated as "pods" in (a) monitoring instance(s) responsible to store & display results? I was thinking simple checks run as scheduled tasks, collection through rsyslog. For the displaying part YMMV, depending on which you merely wanna display or allow viewers to query on the dataset... hence either a static display or more evolved stuff like Grafana. Has anyone built such a thing recently with maybe more proper architectures, yet agent-less, than this one? The usual monitoring setups I encountered so far tended to be locked to the previously chosen tech... for better or worse. Decoupling is good. This would pave the way for check coming from many networks/IX/equipments/hosters, etc. balancing/nullifying observation biases. Interesting idea, but that opens a weird can of worms, e.g. quality and reliability of the data, biases, even privacy and a bunch of things that won't come to me right now. So, it *is* interesting, but it may be a bit of an overkill for this particular instance of this class of issues? Regarding public grafana dashboards, they have an issue, and it's that by having a public dashboard you effectively disclose the whole data source since grafana only acts as a proxy that passes queries to the data source. It's pretty trivial as well, just use the network tab and find the API calls, open in a new tab and modify the query away :-). https://community.grafana.com/t/how-to-make-one-live-dashboard-public/12819/2 It may not be a problem if you consider the data source to be public anyway. FWIW, when I said "I'll see if I can set up sth", I had in mind a thing we started as a PoC on a public status page, but it hasn't been brought up to being actually working publicly, e.g. for Devuan. https://github.com/evilham/prometheus-adlermanager If we get more reports we totally will, so far everything is "looking good" and all tests pass, but maybe there is indeed something inherently spotty on the connection and that's what you are seeing; we'll see if with more data or more reports or when the maintainer takes a look something changes. IIUC, this lack of detection seems to be coming from the lack of monitoring... hence my ping/call to the community :o) Anyone jumping on board is warmly welcome! Oh, there is monitoring, it's just, you know, you can always monitor more and better :-p. In any case, just be respectful towards the mirror admins and don't do crazy things like checking that everything is equal bit to bit every 30 minutes :-). -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
Hello, On dc., jul. 17 2019, Bernard Rosset via Dng wrote: After I stumbled, by chance, on mirror 141.84.43.19 (being part of the deb.devuan.org pool) being unavailable for a couple of minutes, I set a script up checking TCP/80 availability for all of mirrors in said pool. The conclusion is clear: 1°) 141.84.43.19 is the only mirror suffering from this problem 2°) This problem was detected with a high frequency, despite relatively infrequent checks (1 every 5 min) For this day only so far, 2019-07-17, at 1600Z, all the failed occurences were happening at those times: 0050Z 0055Z 0100Z 0105Z 0110Z 0115Z 0120Z 0123Z 0145Z 0150Z 0155Z 0200Z 0205Z 0230Z 0240Z 0245Z 0250Z 0310Z 0410Z 0420Z 0455Z 0510Z 0515Z 0520Z 0535Z 0610Z 0615Z 0630Z 0640Z 0645Z 0715Z 0755Z 0800Z 0805Z 0825Z 0905Z 1035Z 1100Z Very interesting, we'll raise the issue with the mirror maintainer, thank you for going the extra mile than just shouting "it's not working". This report actually helps. Hence the following questions: a) Am I the only one observing this (ie someone else having set such a check up with a check frequency relatively close to mine, eliminating biases of my setup)? We have somewhat thorough mirror checkers in-place that haven't detected this, since they are thorough, they can't run too often as they can result in huge amounts of traffic. FWIW: I've been running "while; curl; sleep 30" as a similar test for a good few minutes now and it's been solid. But maybe it'll be interesting to add simple monitoring at a connection level same way you ran your tests. I'll try to setup a thing in the next couple days. b) If not and this a confirmed defect, would not it be reasonable to remove said host from the pool until the maintainer can inspect what is going on and act on it? If we get more reports we totally will, so far everything is "looking good" and all tests pass, but maybe there is indeed something inherently spotty on the connection and that's what you are seeing; we'll see if with more data or more reports or when the maintainer takes a look something changes. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services
\o/ this is pretty cool and significantly more than I thought would be the beginning. On dv., maig 10 2019, Martin Steigerwald wrote: And now feel free already to contribute your own services. :) I welcome merge requests. Let me just add: not only creating the Merge Requests, but also requesting support for X should also be helpful in that we get to know which packages and user-services are having issues with. Of course, ideally: contributed work is better than just asking for things to get done :-). Maybe the path to officially supporting runit can start by calling everyone who uses it one way or another to contribute some svdirs. There are quite some ideas on how to improve this initial proof of concept: - Make it work out of the box with .xprofile (or how that is called). /me looking to Evilham now :) There is not much to it really, a line I'd use in ~/.xprofile is something like: /usr/bin/runsvdir -P "$HOME/.services/enabled" "log: " & And it should start and stop along with the X session (I don't think it's a good idea to have these services start on regular sessions). - Make it work with other desktop environments out of the box Using the above should do that. - Make it handle groups of services in a clean and simple way - Make it work with s6 alternatively (may just need replacing runsvdir) - And of course add more services, … - including any of those relevant in /usr/lib/systemd/user/ - Putting it into a package. I am willing to package it at a later point in time. When discussing this, please make sure doing so constructively. Thanks a lot to Evilham for coming up with the idea to use runit for user services and for providing the initial service directories for the four services to make Evolution work. Thank you for looking into it and actually documenting it and improving on the whole thing. Now let's make more out of this by the power of together… and of course enjoy using it. Yes! -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] cannot reach gitlab
Didier Kryn writes: Hello. I have had a few authentication failures this morning trying to clone and push my project on Devian's gitlab. Now I get a timed out connection either with git or with my browser. Am I banned or did I crash the git server ? Sorry if I tried crazy actions. I'm new to git. Didier Hello, I took a quick look and don't see anything strange with your user / repos and things appear to be working alright on the server end. If you keep having issues maybe come around to IRC and with a more synchronous communication we can try to figure it out. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt : >On Tue, 23 Apr 2019 12:22:44 +0200 >Didier Kryn wrote: > >> Hello Devuaneers. >> >> I have put on https://git.devuan.org/kryn/hopman an application >> to let mount/umount/open filesystems on hotplug mass storage devises >> such as USB sticks or SD cards. This is a replacements for features >> provided by Desktop Environments. > >[snip] > >OUT-standing > >I didn't have a ready to use Devuan VM, so I just installed it on Void >Linux. It worked perfectly, once I understood the deal. > >A lot of the stuff I report here might not happen on Devuan, but then >again I might find some errors or maloptimizations that might be edge >cases in Devuan. > >Anyway, I followed your compile instructions and it worked perfectly. >But when I ran hopman, I got a "Bus error" message running it as either >slitt or root. So I touched /home/slitt/.hopmanrc, got past the bus >error, but got another error. Infatiguable, I copied the entirety >of /etc/default/hopmanrc to ~/.hopmanrc, and the thing began to work. > >For those of you who haven't tried hopman yet, let me define "work". >You run hopman on the command line, and it sits there and spins. No >gui. *Until* you insert a thumb drive. Then, all of a sudden, the gui >pops up with the thumb's label. Left click the label line and you get >choices to open in filemanager, open in terminal, mount, or eject. >Regardless of what you set EjectHelper to in .hopmanrc, trying to eject >always errors saying "No command helper". This is true even if I set >the EjectHelper to the same string as UmountHelper in ~/.hopmanrc. I >have a hunch something's hard coded that shouldn't be. One of the >source >files (config.c I think) mentions there's no known EjectHelper. > >Hopman didn't show up anywhere on my lxpanel: I have a feeling that was >a design decision so hopman doesn't need to know the intracies of each >panel it interfaces with. > >Bottom line, a running Hopman shows a GUI window *only* if thumb drives >or USB harddisks are plugged in. > >Like almost every other mounter software, hopman gets itself in a crazy >state if you yank the thumb drive out before unmounting it. In this >crazy state, it tells you you can't unmount it because it's in use. >This also happened on my inotifywait based mounter (which another >Devuanner improved substantially). I'll research this more. > >I'm trying to create a runit run file for hopman and am having a little >trouble. I'll report back later. > >One more thing: Hopman is wonderful software. Very few dependencies, >easy as hell to compile. No ./configure step. No BS. The source is >fairly easy to read. It does one thing and does it well. This is how >all software should be written. > Thank you for the review! I had the feeling this would be quite nice :-). If I may recommend, open 3 issues on gdo (on phone, about to sleep, else I'd do it): 1. Improve documentation / UX by communicating the "No GUI until you plug sth" behaviour on stdout. 2. Either gracefully treat a packing rc dir or to create it automatically or just to have a good stderr message 3. Document the misbehaviour when users... Misbehave (okay, that was a bad joke). I think, 1 and 2 are easily actionable and, from what you described, would greatly improve the UX. 3 may be trickier. -- Evilham___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Didier Kryn writes: Hello Devuaneers. I have put on https://git.devuan.org/kryn/hopman an application to let mount/umount/open filesystems on hotplug mass storage devises such as USB sticks or SD cards. This is a replacements for features provided by Desktop Environments. It only depends on a linux kernel version newer than 2.2.26 and the GTK+-2 library, plus helper commands to mount/umount/open the filesystems, such as pmount/pumount, thunar and xfce4-terminal. That's great, thank you. The git repository contains a description of the project, plus a directory containing the source and makefiles. To instal: git-clone the project, then: cd hopman/hopman-1.0 make && make install # You must be root to install make cleanall Installed files: /usr/bin/hopman, /etc/default/hopmanrc, /usr/share/man/man8/hopman.8.gz,, /usr/share/pixmap/hopman.png, /usr/share/applications/hopman.desktop I tried to make it a Debian package, but with little success. I need help for that. I hope someone can devote some time to help with this. I also need help to remove from the gitlab a previous, primitive version which was named partmon. I transfered that repository to my user on gdo and if there are no complains I'll delete it in a couple weeks, I hope that's acceptable. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Am 9. April 2019 10:53:40 MESZ schrieb aitor : >Hi all, > >On 4/2/19 7:35 PM, Andrew McGlashan wrote: >> Many April Fools are done/around/ the time of 1st April some >get >> in early on purpose, irregardless of time zones. >> >> Still, moving on; we've been promised that this won't happen again. >> >> Thank you. >> >> Cheers >I didn't know about april's fools until this all happened because of >our >different traditions: we use to do this sort of jokes on 28 December, >called "El día de los inocentes" and which, as you will remember, >coincided with the death of Ian Murdoch. During this incident happened >I was preparing my travel to Amsterdam and I couldn't take time off to >follow the thread closely, even being aware that something serious >happened. In spite of I try to mantain aside of this kind of incidents >(in part because english is not my native language and I can >misundertand >messages), i'll draw a positive conclusion... People involved in the >incident have been in Amsterdam during these days because all of them >love Devuan the project. They are mature people, and mature people try >to understand the emotions and reasoning of others. >Seeds of discord comming from the distance are insane :-) Well put, thank you Aitor and Andrew! Indeed dev1-conf was (and is being) very positive for many aspects of the project and this is just one of them. -- Evilham___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What you saw on devuan.org yesterday was an April's fools joke
Jaromil writes: he is now in moderation. if the trolling comes back from other accounts please don't feed. Thank you, I was coming to suggest that as well. The whole going-for-blood-or-else thing was getting on my nerves. People particularly concerned with security did the sensible thing as a temporary measure and with all the assurances already given, are back to normal as there is indeed no ill-intent or reason to distrust the people with access to infrastructure. Also thank you for the non-exhaustive list of KatolaZ' contributions; I didn't personify this, even if he apologised (which is indeed highly appreciated), because I don't consider this event a few people's fault, but something to be analysed and solved to avoid issues in the future. In my experience, blaming never solves things. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Mike Bird writes:
On Mon April 1 2019 14:18:38 Martin Steigerwald wrote:
For me that is good enough.
When core team member Evilham writes "it still looks as
if gdo and the build system were compromised" [1] I need a
lot more than a limited admission of guilt from KatolaZ
before trusting that Evilham was mistaken rather than
KatolaZ just managed to hide his tracks better.
Obviously, even when trying, it is impossible to pick words in a
perfect
way since natural language is imprecise.
You are reading too much into that phrase.
In the context, it referred to the "pwned site" (still viewable)
**claiming** ("looks as") that gdo had been compromised.
If you read a paragraph further, that point is made very clear,
when I
mention that the "joke" wouldn't have been half as bad if it had
been
limited in scope to the plain devuan-web.
I kindly ask you not to read things that are not there and jump to
conspirations, it is what it is: a fuck up, a beautifully executed
one,
but a fuck up and a recognised one at that.
Discussing at this length what the fine letter said is not going
to help
move things forward, quite the opposite.
Again: there is no reasonable ground to think devuan the signing
keys
have been compromised or anyone with access to infrastructure is
acting
with ill-intention.
This email could have been signed, but being abroad and all,
access is
not the most trivial and it likely won't suffice for you, so I
have
better things to do, like sleeping!
--
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Evilham via Dng writes: Evilham via Dng writes: (*): **to my knowledge** means that I am still trusting the communications and the project, even if I decided keep in place the temporarily disconnect of my systems from devuan's infra. FWIW if anyone cares, I checked what I could and things under my control are back to using devuan's infra. Everyone please abstain from escalating things forward, suggesting kicking someone out of the project or taking legal actions is premature; and claiming it's a harmless joke and everything is fine is is also missing the point. If I disconnected my systems from Devuan's infra was because it was the prudent thing to do while things were clarified, if I am satisfied with shallow tests is because I have no real reason to believe this was but a misdirected prank with all the "buts" I explained before. That message was just intended to help those who are so rightfully concerned about this see, that their views are also being taken into account and not ridiculed and left forgotten. My guess is that this will be discussed at length... Yes, at dev1conf, in person, where text will be much harder to be misinterpreted than on emails. Until then, speculation and pointless debates are just noise. And if it has become personal, take it to a private space. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Evilham via Dng writes: (*): **to my knowledge** means that I am still trusting the communications and the project, even if I decided keep in place the temporarily disconnect of my systems from devuan's infra. FWIW if anyone cares, I checked what I could and things under my control are back to using devuan's infra. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
