57[00:33:40] <cybrNaut> apart from firmware, more generally, suppose i have a Buster blu-ray disc, and because of popcon some unpopular pkgs are missing from that disc. Is digging through Releases.gz then finding the deb in pool/* a sensible approach, assuming the target host is not yet online or hardened?
58[00:34:01] *** Quits: aaii (~aaii@replaced-ip) (Remote host closed the connection)
88[00:54:42] <cybrNaut> apt-cdrom didn't work for me.. apt update failed after that. But i got it sorted. I had to workaround that by mounting the ISO and then using "deb file:///mnt/my-iso-mountpoint ..." and that worked
138[02:44:19] <sussudio> Buliarous: /msg dpkg debian clone It's sitting outside the channel, so i don't know if it will still respond.
139[02:45:26] <Buliarous> sussudio: not getting a response unfortunately
140[02:46:06] *** Quits: wyatt8740 (~wyatt8740@replaced-ip) (Remote host closed the connection)
141[02:46:38] <sussudio> Buliarous: <dpkg> One method of cloning Debian installs is to take a current Debian machine that is set up with the packages you want and run the command "dpkg --get-selections > ~/selectionfile". Then, after the base install on other machines use that file and do: "dpkg --set-selections < ~/selectionfile && apt-get dselect-upgrade".
398[14:25:52] <egawrilow2016> Hello, Debian community. I have question. I have error in Debootstrap image launched in Termux's Proot. This error manifests in APT and DPKG. How to solve? Log: replaced-url
435[14:49:52] <oxek> yeah, I can understand that. The frustration of channel ops can be felt by everyone by now.
436[14:50:13] <jelly> that's not an official opinion, just my own. You'll note I've kept away from OFTC #debian for the most part, I just can't deal with 2+ channels doing the same thing
437[14:50:17] <jelly> let alone three
438[14:51:02] <jelly> and OFTC now has the largest #debian
439[14:51:38] <oxek> I'd be happy with moving myself to OFTC, but based on talking to OFTC staff I still need to wait for them to switch to a newer ircd before SASL is working and my account could be whitelisted based on SASL
440[14:51:55] <oxek> I'm on bad IP addresses that get killed immediatelly when spotted
441[14:52:11] <oxek> like, it doesn't even let the TLS terminate properly
455[14:58:37] <jelly> I mean you seem like a reasonable enough fellow that I could set up a separate znc instance on my vps for
456[14:59:36] <synthetek> I went to the new chat once.
457[14:59:40] <oxek> jelly: thank you for the offer, but I have no plans for that yet. I'll check out how interesting the #debian channel is on libera, if I can still keep on learning things in there, and if not then I'll probably need to get myself to switch ISPs for a number of reasons anyway
458[14:59:48] <oxek> maybe starlink will be the solution for me
459[14:59:56] <jelly> nod
460[15:00:35] <jelly> starlink is going to KILL in the rural regions if they can scale
461[15:00:41] <oxek> exactly
462[15:00:57] <jelly> africa is going to be all Elon
506[16:11:20] <cybrNaut> apt tools check the hash and sigs, & refuses to install unverifiable packages, or so i thought
507[16:11:27] <erts> Hi, I'm using Debian with KDE Plasma. It works perfectly, but if I choose a different window manager and log in from SDDM, on some of them the screen background doesn't change, the SDDM view stays on the screen even though the WM is totally usable, but the background doesn't refresh. Any idea about this?
508[16:12:02] *** h4x0riz3d is now known as antto
509[16:12:59] <cybrNaut> there's no way for apt to check the authenticity of a deb file on its own, so it should reject them
519[16:34:53] <cybrNaut> oxek: privs is moot. If you don't have the privs then there's no discussion. If you have the privs to install something, either you have an expectation for the tool to protect you or you don't. It can't be halfway because that's a recipe for disaster (the user expects more security than they actually get).
520[16:35:51] <cybrNaut> i recall aptitude refusing to install something for me once because the authenticity didn't check out. And rightfully so.
521[16:36:21] <cybrNaut> it's a security bug to say the least.
559[17:26:18] <cybrNaut> indeed. some debian mirrors don't even support TLS (and zero Ubuntu/Mint mirrors are secure). I thought there must checks on the packages happening, because no way would it be a norm for the whole population to trust http traffic in the clear. bad assumption.
560[17:28:07] <cybrNaut> i've always insisted on either https or onion, thinking that was just a matter of disclosure. But it's worse, if pkgs don't have sigs that are being checked individually
561[17:28:56] <tomreyn> cybrNaut: out of interest, what makes you say that "zero Ubuntu/Mint mirrors are secure"? do you mean "secure" as in "https" there, or something else?
562[17:29:18] <cybrNaut> tomreyn: i just mean https in that context
563[17:29:41] <cybrNaut> no ubuntu or mint mirrors supported https last time i checked
564[17:29:44] *** Quits: igrtrrt (~igrtrrt@replaced-ip) (Remote host closed the connection)
565[17:30:29] <tomreyn> it must have been a while that you checked
566[17:30:44] <cybrNaut> and no onion mirrors exist for ubuntu or mint either
567[17:31:00] <cybrNaut> ~2-3 years since i checked
572[17:32:35] <tomreyn> i see, i can't challenge that.
573[17:35:02] <cybrNaut> and since then, recently, Mint has moved their docs into Cloudflare, so security is dodgy for Mint users anyway. If the project is willing to use CF for docs, what other stupid things are they doing?
574[17:35:32] <cybrNaut> I used to install Mint for novices, but no longer
575[17:50:34] <cybrNaut> so to reach a reasonable level of security, we should give the "--download-only" option to apt*, visit replaced-url
576[17:52:45] <oxek> that's absolutely pointless
577[17:52:59] <oxek> you could just do `apt download <packagename>`
590[18:03:51] <cybrNaut> well then my original point stands -- that *.deb files are not hash-checked when fed directly to apt, yet they are hash-checked when taken from a mirror
591[18:05:20] <cybrNaut> apt* should either: 1) warn the user that the hash was not checked when a raw deb file is fed to it, or 2) refuse to install a deb file unless the user supplies an option like --no-check
669[19:26:42] <coc0nut> cybrNaut, debian (apt) isnt proprietary. its open source, wich means you can freely modify and edit the source code. its not like debian is doing the security for you. you do whatever you like. so demanding a warning for hashcheck is kinda stupid... osx does it. and windows allow you to check for only using store apps..
670[19:27:32] *** Quits: nicopok (~nicopok@replaced-ip) (Remote host closed the connection)
671[19:27:59] <cybrNaut> coc0nut: who does the work is always a red herring wrt what needs to be done
672[19:28:34] <cybrNaut> it makes little sense to do all the work that a PR entails if it will only get rejected in the end
673[19:29:27] <cybrNaut> the 1st step is to report the bug. the next step is to discuss. the last step is to do the work. Putting the work first is backwards
674[19:30:03] <oxek> the PR would get rejected, yes
675[19:30:08] <coc0nut> ofc its a good thing. and if you want your app to be liked, you surely want to add a hashcode for the original file. just that if your adding a deb package you should know what youre doing, or atleast experiment in safe env
685[19:43:28] <cybrNaut> "if your adding a deb package you should know what youre doing" <= users have the *option* to look at the apt source code in order to see how the hashes are checked, but it's reckless to design software that *requires* users to inspect the source code in order to know what the app is doing.
694[19:48:03] <oxek> .deb files do not contain a signature on them
695[19:48:10] <cybrNaut> it's unreasonable to assume users know the internal structure of deb files
696[19:48:41] <cybrNaut> or that they read the source code
697[19:48:45] <oxek> anyway, this really isn't a debian problem
698[19:48:54] <oxek> there is no threat model here
699[19:49:05] <oxek> and no description of any vulnerability
700[19:49:39] <coc0nut> its free... its not like theyre selling it, they dont care about competition/sabotage in that way. i get your point, but you use open source projects on your own responsibility i guess. that sounds fair to me :p if they were selling it, having costumers paying for it, it would be a totally different thing. having securities like copyright limitations and stuff.. then its not open source. and its not even linux. the freedom to do what you like with your
701[19:49:39] <coc0nut> stuff. its priceless :p
702[19:50:40] <cybrNaut> corruption is in everyone's threat model. You people who learn about infosec from hollywood movies have no idea what security is.. that anything (even accidents) that harm data integrity are a security issue
703[19:50:47] <oxek> let me ask you this cybrNaut, when you download a video file, and double click it, do you expect it to be hash checked by the media player? When you download a text file, do you expect the text editor to do a cryptographic verificiation it is the file you downloaded? Same with pdf, docx, ...
704[19:51:05] <cybrNaut> security is not always about fending off hacker attacks
711[19:52:30] <valgren> the default way of using an official repository is quite save, i guess. downloading .deb files and installing them is like downloading an .exe file on windows and just clicking "install anyways" in that fancy pop-up. So, even in other operating systems, they see it as your own risk as a user to use downloaded files.
722[19:55:18] <cybrNaut> accidental integrity loss *is* a security problem -- and hashing addresses it
723[19:56:16] <oxek> Present an argument for why apt should warn the user that a checksumming filesystem is not in use, that ECC RAM is not in use, that a file was not downloaded from sources listed in sources.list, ...
724[19:56:49] <coc0nut> cybrNaut, you have to do your homework to get secure. I feel more secure in a open source community (the people), than in a corporate like microsoft (owned by governments)...
725[19:57:11] <cybrNaut> oxek: i don't need to -- my stance doesn't require apt to be filesystem-aware
726[19:57:37] <oxek> cybrNaut: and hashing exists at every step of the way. apt verifies the hash on download, ECC ensures integrity is preserved in RAM, btrfs ensures integrity is preserved on disk, cryptsetup ensures data is safe at rest, ...
727[19:58:03] <cybrNaut> coc0nut: i'm not just interested in "feeling" secure. a false sense of security is dangerous
728[19:58:35] <valgren> i bet someone could forge a hash for a file and set it up for download. then even if apt would check the hash, it would continue to install. we have projects where we build our own .deb packages for our customers with our own generated hash values in the corresponding Package files. apt just installs them as if they came from an official repository. so hashing does not completely help you with security, i think?
729[19:58:40] <coc0nut> well, being not only once said that you are never totally secure.
730[19:58:42] <cybrNaut> oxek> cybrNaut: and hashing exists at every step of the way. <= nonsense. it's skipped. hence this bug: replaced-url
731[19:59:58] <oxek> cybrNaut: that bug is the exact example of filesystem corruption, had btrfs or zfs been in use, it would not occur
732[20:00:00] <cybrNaut> valgren: you're right. hashing protects from /some/ security issues and not others. debian falls short on this
734[20:00:57] <cybrNaut> valgren: ideally, every pkg is crypto signed and apt checks the sigs using pubkeys on the keyring
735[20:01:53] <oxek> when a file is verified after downloading it, it is no longer untrusted input. If something corrupts it in RAM or on disk, then you need to look into ECC RAM and checksumming filesystems. It's not a security issue for apt.
736[20:02:33] <cybrNaut> oxek> cybrNaut: that bug is the exact example of filesystem corruption <= as i said, it's an example of a single point of failure where apt installed a corrupt pkg
738[20:02:58] *** Quits: Vizva (~Vizva@replaced-ip) (Remote host closed the connection)
739[20:03:07] <cybrNaut> how it got corrupted is only relevant to the *first* point of failure, not the second
740[20:03:19] <valgren> cybrNaut: maybe, this is just a bit too much paranoid for a program like apt. i still need elevated privileges to do real damage to my machine or installing software with apt. so "I" am responsible for what i download
741[20:03:26] <oxek> cybrNaut: it's dpkg, not apt in there
742[20:04:13] <cybrNaut> division of duties. apt does the checking, not dpkg
743[20:04:24] <oxek> and hardware issues are out of scope for both apt and dpkg.
744[20:04:51] <oxek> hardware issues are out of scope for cryptsetup, veracrypt, keepassxc, ...
745[20:04:54] <valgren> i thing, the last instance of security could really just be the human sitting in front of the keyboard.
746[20:05:01] <cybrNaut> oxek: clearly all the multiple points of failure arguments went over your head
754[20:07:47] <coc0nut> I had an incident the other day, where installing a git-all package ruined my system. because it conflicted having my system uninstall vital parts. I guess it would need proprietarity to make sure everything is in place all the time. like alpha, beta gaga testing. even microsoft and apple can do mistakes like that probably
755[20:08:19] <valgren> cybrNaut: i also work at a software project where security is vital but we also have to consider what is practical in terms of computational resources and usability for our customers. at some point adding more security eats more money than our department has available for the project
756[20:08:32] <oxek> coc0nut: your problem wasn't installing git-all, it was running the autoremove afterwards
757[20:08:52] <coc0nut> but then again, it was me clicking enter to fast in the question if i would like to perform the action of autoremove
758[20:08:56] <coc0nut> your right oxek!
759[20:10:29] <wyatt8740> upgrading an old Dell latitude D610 I used to use from Debian Wheezy to Sid… wish me luck.
760[20:10:51] <oxek> wyatt8740: one release at at time?
761[20:11:07] <wyatt8740> nahh
762[20:11:09] <wyatt8740> one shot
763[20:11:15] <wyatt8740> >:)
764[20:11:31] <wyatt8740> and then clean up the mess later
765[20:11:44] <oxek> keep in mind that that is unsupported
766[20:11:45] <valgren> wyatt8740: do a backup/mirror of your hdd before you do the upgrade to have a save way back :)
767[20:11:48] <wyatt8740> yeah i know
768[20:11:57] <wyatt8740> Nope, not much i need on here anymore
770[20:12:11] <cybrNaut> valgren: indeed costs are part of security. Security costs money, but we do it because saves money by mitigating catastrophe. It's a balance of costs and in the commercial environment it's just down to the bottom line. Free software is not constrained in the same way though. You can have more security in free software than what would be commercially viable.
772[20:12:39] <wyatt8740> oxek: i'm using Sid and I also have a Powerbook G4 running sid; I
773[20:12:45] <wyatt8740> *I'm pretty used to unsupported stuff
774[20:13:09] <wyatt8740> so far as ports.debian.org is unsupported
775[20:14:25] <cybrNaut> valgren: it's the same as testing. Testing costs money, but it saves money. Some projects naively cut testing when the budget shrinks.. which is obviously a stupid move when you consider that the purpose of testing is to save money by catching bugs early
776[20:14:27] <valgren> cybrNaut: and that is what i bet on. open source will lead to better security but it takes more time. there is no contract that says "have security feature xy after z months". it's an evolutionary process, but i can live with that as long as i am aware of the consequences of my doing (installing packages and so on)
777[20:14:53] <cybrNaut> valgren: exactly
778[20:14:54] <valgren> cybrNaut: yeah, testing is one hard nut to crack in our project, because of the time constraints :D
779[20:17:00] <sussudio> wyatt8740: sid is not an upgrade.
780[20:17:01] <cybrNaut> valgren: note that fixing apt would be cheap. it would be trivial to hash a local deb file, show the hash to the user, and wait for "yes/no" whether the user confirms a match. that would be a very cheap fix IMO
783[20:18:50] <valgren> cybrNaut: if apt would show a long hash number, the user would probably not care and press 'y' just to get his new shiny program up and running. an automatic validation would be better.
785[20:20:22] <valgren> cybrNaut: oh, i got it, the user gets the message that the hash does not match and has to confirm the install/update (much like MS asking for "install anyways?") but if that would be more secure? i don't know, even doubt it
786[20:20:53] <cybrNaut> valgren: i agree, but just in terms of doing a cheap fix it would go a long way. The software can help prevent a user from accidentally or carelessly shooting themselves in the foot, but can't do much against a user determined to do self harm
787[20:21:01] <valgren> cybrNaut: the thing is, most users are "idiots" (including me sometimes :D )
788[20:21:31] <coc0nut> people are idiots, computers are stupid
789[20:21:59] <valgren> cybrNaut: yes, it's like the questions about the maintainer scripts you get from time to time, it let's you stop an think for a while
790[20:22:00] <cybrNaut> indeed. some users will burn themselves even with good guidance. That doesn't mean we decide to toss out good guidance
791[20:22:20] <coc0nut> mistakes is the best lessons too
792[20:22:48] <oxek> cybrNaut: you're missing the point that the computed hash cannot be compared to anything, if you haven't provided a hash yourself. At which point you can already use `sha256sum` or other utility to do the same, or if you have cryptographically secure hashes then there's .asc files and gpg for that.
793[20:23:14] <valgren> oxek: yes, that could be a problem...
794[20:23:19] <oxek> all these tools work together, but if the user chooses to avoid them, then the responsibilty falls onto that uesr
795[20:23:35] <oxek> and what you're describing is intentionally avoiding those tools
797[20:23:44] <oxek> hence completely out of scope of anything
798[20:24:09] <coyotes4ys> so i've been using brave browser. i think i need a different browser. it doesn't seem free
799[20:24:14] <coyotes4ys> any suggestions?
800[20:24:23] <oxek> coyotes4ys: there's always firefox in the debian repos
801[20:24:31] <coyotes4ys> lol
802[20:24:39] <coyotes4ys> thank u though oxek
803[20:24:53] <valgren> in good unix philosophy, these tools need to work together, maybe someone turns apt into a script that smokes these tools through a nice long pipe :D
804[20:24:59] <jelly> two things to note: /usr/bin/apt is a tool for interactive use; it has no API or syntax set in stone yet; and the new-ish apt install ./foo.deb syntax is obviously a shorthand/shortcut to make installing local, custom packages easier
828[20:39:35] <wyatt8740> there's plenty of reason to be nervous about it, but I learned a lot
829[20:39:50] <wyatt8740> if you have a low stakes system it might be a good place to try it
830[20:39:54] <wyatt8740> (assuming you have time)
831[20:40:11] *** iPodClassic is now known as iPodClassic^[AFK
832[20:40:14] <iPodClassic^[AFK> BRB!
833[20:40:46] <wyatt8740> honestly i don't see things break very often, but one must always be a little more careful
834[20:42:48] *** iPodClassic^[AFK is now known as iPodClassic
835[20:43:02] <valgren> i used stable for a long time and at some point things even break there, but that is by my own doing. i don't like to spend an afternoon reinstalling the system and copying backups and configuring the system, because most often the latest config is not in the backup :(
837[20:43:29] <valgren> and the change with sid is greater i guess to break something
838[20:43:44] <valgren> the chance
839[20:46:32] <wyatt8740> i have had the same sid install on my main desktop at home since 2014
840[20:46:54] <wyatt8740> it's starting to get a bit messy in terms of how I've added more storage over the years, but it remains pretty steady
841[20:47:16] <wyatt8740> package management isn't broken yet or anything :)
842[20:48:36] <valgren> wyatt8740: with all that knowledge from fixing/maintaining the system, have you ever considered building your own system? that would be my next step; building something with yocto/busybox but i've only watched some vids on youtube about these tools and i'm not sure if i want to go that way right now
843[20:49:06] <wyatt8740> valgren: eh, I don't feel the need, although honestly my system is pretty much its own thing at this point
845[20:49:38] <wyatt8740> I've considered it, yeah
846[20:50:05] <wyatt8740> but I just have a couple debian packages I tweak myself and I otherwise depend on the debian repositories.
847[20:50:20] <valgren> i have some old hardware that would benefit from a smaller kernel image, less modules to load/run in the system, and it would only contain things i really need
848[20:50:58] <wyatt8740> I've run FreeBSD/OpenBSD and stuff on things before, too, and I have built my own kernels, but i tend to leave them rather large even on old systems just so I don't have to rebuild if I get a new card or USB device
849[20:51:49] <wyatt8740> I think my machine with the least ram right now has 1.5GiB
850[20:51:50] <valgren> yes, if you upgrade the hardware it would be better to leave the support in the kernel
851[20:52:08] <wyatt8740> I mainly worry about "what if I get a new video capture card or something"
852[20:52:21] <wyatt8740> because I don't want to wait an hour and a half at that point before I can use it
857[20:58:02] <wyatt8740> valgren: Sort of? i usually have modules for the hardware that's permanently installed load at boot (from /etc/modules), but i will build modules for things I might not have, like a drawing tablet, a video capture card, etc.. Then, when I plug the device in I can load a module for that card and that's when it will take up more space in kernel memory. But until that point it's just waiting to be used on the hard disk
858[20:58:23] <wyatt8740> I do load up all my permanently installed hardware at boot time, though, either baked in completely or as a module
859[20:58:56] <wyatt8740> so since I have no intention of upgrading my sound card (audigy 2 ZS, uses the emu10k1 module), I'd put that in /etc/modules
860[20:59:25] <wyatt8740> but my video capture USB (uses the em28xx module) won't get put in there because it'd be wasting RAM if I didn't use it.
861[20:59:36] <wyatt8740> i'd have that one load when plugged in
862[21:00:02] <wyatt8740> i believe debian already does it like that (not loading stuff until needed)
863[21:00:16] <wyatt8740> i just hardcoded some of it into /etc/modules because a bit of it is init-system dependent
864[21:00:27] <wyatt8740> (if it gets autoloaded or not)
865[21:00:55] <valgren> so it is like a custom kernel, that's kind of what i would like to try a some point in the future, building a minimal kernel; the idea of loading the modules later is a really good idea
866[21:01:57] <wyatt8740> yeah, if you're in doubt and you have hdd space (they don't really use THAT much relatively speaking) i just follow make menuconfig and do what they suggest, picking modules where necessary. If there's something I'm 100% sure I won't use (for instance, hot-plugging CPU's) I'll disable that.
900[21:14:28] <wyatt8740> i think rms accepted hurd wasn't going to hit the primetime a long time ago
901[21:15:30] <wyatt8740> and it's been around 40 i think
902[21:16:30] <wyatt8740> ah, 38
903[21:17:34] <valgren> yes GNU started in 1983 and that was for the better for linux (1991) because "all" the necessary parts for the operating system (except) kernel were there, Linus just had to use them and here we are today, using GNU/Linux
904[21:19:18] <valgren> funny thing, i've switch to linux just "recently" about 2008/2009; i grew up using dos and windows
973[21:45:57] <wyatt8740> don't plan to do that here unless systemd _REALLY_ messes things up; that's the biggest difference between wheezy and current i think
974[21:46:22] <wyatt8740> well, that and newer libc and such
975[21:46:24] <wyatt8740> and kernel
976[21:47:20] <valgren> my own experience with upgrading the dist was that they changed the device paths to UUIDs and that screwed everything up, had to manually fix it, same later for the network cards...
1071[23:21:18] <Ede|Popede> heh, makes me think of all the fun some years ago on facebook and elsewhere where some rightwing idiots started the story that the antifa got paid by the government to appear at demonstrations
1072[23:22:06] <Ede|Popede> within a few weeks TONS of fake antifa-profiles appear claiming to be the official transportation company, the antifa union, antifa event catering, what not