Re: Guest Post Request for lists.debian.org
Paul Wise dijo [Tue, Mar 16, 2021 at 05:05:43AM +]: > On Tue, Mar 16, 2021 at 4:42 AM Gunnar Wolf wrote: > > > Thank you for your offer. The Debian project is not interested in this > > kind of collaboration. > > That was clearly a spammer, best get listmasters to ban them rather > than responding. That is clear to me. But having them re-send their message four days later means they are most likely not a stupid spammerbot... That's the reason I replied. Greetings,
Re: Guest Post Request for lists.debian.org
Eve Maygar dijo [Mon, Mar 15, 2021 at 11:03:30AM -0700]: > > I work as an educational specialist on the PapersOwl service. I am doing > > collaborations with other websites. It seems to me that we can create an > > interesting article for your readers. I wanted to place a guest post with a > > link to my resource. Is it possible? What conditions? > > > > Here are examples of our previous guest posts: > > https://www.ava360.com/what-education-should-be-in-the-21st-century/ > > https://www.theinspirationedit.com/how-parents-prepare-students-for- > > college/ > > https://www.swaay.com/how-to-manage-your-time-better-as-a-student > > > > Looking forward to your reply. Thank you! > > Hi, > > Any updates? Hello, Thank you for your offer. The Debian project is not interested in this kind of collaboration.
Re: new hash algorithim for git and maybe a goal for Bullseye ?
shirish शिरीष dijo [Wed, Feb 05, 2020 at 05:00:16PM +]: > Dear all, > > Please CC me if anybody feels like answering. > > I was shared this [1] and while it's important, it is equally > important to point out that the work isn't complete atm. From what > little I know, almost all Debian's work is now using git (there may be > some subversion, some mercurial repos) but most of the work has now > been using gitlab/salsa [2] . While some of the comments suggest that > SHA-1 is fine for now one doesn't really know. From what little I can > make out, it seems a pretty disruptive change and may have gotchas > also for the reproducible builds project. [3] Hi Shirish! There is a very nice article presented in LWN two days ago explaining more the issue; I will send you a personal mail with a free link to it (for other people, LWN has the policy of opening their paid content a week after publication, so please just wait for five more days). https://lwn.net/Articles/811068/ Git is working towards being able to migrate to SHA256, and future migrations will probably be easier. As of right now, due to the way Git uses the hashes, danger is _not_ imminent and we can keep using it safely; Debian depends on upstream support first being ready before we introduce said changes; even after we introduce them, we need to keep older versions supported at least for a stable+oldstable cycle. So, no, support for SHA1-Git will not be dropped within any forseeable future :-Þ Greetings,
Re: How To Incident Response
lann...@runbox.com dijo [Fri, May 12, 2017 at 04:31:11PM +0200]: > Hi, Hi, > I'm performing installation for a "secure" web app. OK, but I must first point to a minor contradiction here: Your mail's subject talks about incident response, but you talk here about "performing installation". Those are two very different (although, yes, conceptually related) issues. Before going further to your choice of applications, this first step requires understanding what is that you are installing: Which kind of web app? What framework is it built on? Which language does it use? If you are building your application, start by assessing the environment you are building against: Look for known vulnerabilities (i.e. using the CVE database¹), try to assess how frequent and how deep the impact of said vulnerabilities are. Check how long has it taken for issues to be accepted / addressed / solved by the authors. ¹ https://cve.mitre.org/ Of course, try to choose the framework with the smallest attack surface (i.e. if your application can do with a minimalistic framework instead of a full-featured stack, it will probably be better). On the other hand, if you are installing a known program (either free or non-free), you should do the same for the program itself, as well as other programs addressing the same application domain. That's for installation, of course. But your mail goes on to address what your mail subject initially suggests: > I'm starting with psad, and suricata. > > Now I'd like to install Sguil or Snorby or any alternative for packet > capturing. My problem is that I have to compile myself which we know is not > the best solution for security. Keep in mind that for the next release cycle you will probably also have to self-support Snort², as it will most likely be dropped out of testing a couple of weeks from now (#861842). Also, Snorby falls in the case I mentioned above: I quite like developing with Ruby on Rails... But make sure to properly protect the system that will/would host Snorby, as Rails has too large an attack surface for security-sensitive stuff. ² https://tracker.debian.org/pkg/snort The issue with Snorby or Sguil is not compiling them (as they are not compiled - Ruby and Tcl scripts respectively), but supporting them (it's up to you to track and update new upstream versions). It *might* not be much of a burden, but again, check the projects' history; some pieces of software are a manitenance nightmare. > Does any alternative exists? > > Also, Which tool can mail me if there are any alerts? > > Any other tools that I should consider? There are many, many tools that can help you here - but they all depend on you being skilled using them. Intrusion prevention/detection and incident response are not really tasks that can be fully automated. I suggest you take a look at several of the packages that 'apt search intrusion detection' give you; you will find several quite old (although good!) tools as aide or snort; you will find many tools for file-based IDS/IPS (and it seems you are looking for a network-based one). To be honest, a long time ago I did have an IDS system, but in the end I ditched it — Profiling what's "normal" and "abnormal" activity, understanding what appears in your correlator, needs a lot of site-specific, knowledge-intensive work. A useful IDS will also demand a high CPU load, and strategic placement in your network infrastructure. Of course, it depends on your network's needs; given that I'm "just" the network administrator for a smallish research institute with few network-exposed services, we decided after some months the risks were not worth me devoting an almost full time to tracking reported incidents. The difference between IDS and IPS is that the first one reports what has just happened, and the second actually attempts to block attacks from succeeding. An IPS is way more powerful, but demands way more attention - because it can be abused leading to DoS. Anyway, that's the point of view of a small-scale sysadmin who *thinks* does some things right :-] signature.asc Description: Digital signature
Re: Userdata stays in RAM after Logout and Relogin
H. N. dijo [Sat, Nov 05, 2016 at 01:12:47AM +0100]: > > That's what I assumed when I read it: video driver bug. > > It might also be a hardware issue, where graphic RAM is not > > cleared on reset. Or given the nature of video devices, perhaps a > > combination of the two: a driver bug that expects certain generic > > behavior combined with a device that expects a custom, proprietary, > > vendor-provided driver to work correctly. > >(...) > > Thanks for the help. > > My setup, just for information: > Nvidia GTX790 (I think) with 4 screens connected. > Two of the screens are connected by Logilink Adapters DP to HDMI. > I am using the driver from Nvidias Website. > > Can (and should I) report the problem to Nvidia? > > (and recieving Messages from the Mailinglist luckily works) Yes... Although I do not think they will care very much, but it falls within their area of responsability; Debian cannot fix non-free software. Have you tried to reproduce this issue using the free nVidia drivers? You might have some less capabilities (i.e. the ability to drive the four screens) or speed, but it should help you determine whether it's something caused by Debian or by their non-free drivers. signature.asc Description: Digital signature
Re: vacation mail
Jason Fergus dijo [Thu, Aug 07, 2014 at 09:48:24AM -0600]: > Ha, I think it's hilarious when people do this. Also stupid, but if it > weren't for stupid people, who would we have to laugh at? :D Right. And these messages bug us, true. But please, stop it. Debian project mailing lists are not the right place to laugh at people. signature.asc Description: Digital signature
Re: the calculus of encrypting non-textual data (was Re: concrete steps for improving apt downloading security and privacy)
Joel Rees dijo [Tue, Jul 08, 2014 at 11:11:09PM +0900]: > >> Did you know that encrypting a picture sometimes results in a picture > >> that looks like it has been through a random color-permuting filter? > > > > Can you proof it? > > Memory of coursework in encryption. The professor did some simple > encryption on uncompressed images and showed how the results tended > not to hide the things one would want hidden. > > Then he pointed out that the parts of an image with the most > information are the parts that are least likely to compress. And he > pointed out that standard encryption methods tend to be byte-oriented, > for speed. Well... Yes and no. Yes, that happens when you don't do it right. http://gwolf.org/files/desarrollo_y_cripto.pdf#page=40 If you implement the wrong mode of operation (schemes for the five modes of operation shown in the next page), you end up with the problem you mention. This result was achieved using the Electronic Code Book (ECB). Now, the ECB mode should never be used twice for the same plaintext blocks. Oh, and as a sidenote for my images: They are *a bit* tricked. If you apply ECB to a PNG image, as the PNG image is compressed, you will not find this pattern. I saved the original image as a BMP, then ciphered the image, and then copied over (prepended) the BMP header to the new file; that's the reason for the file to be slightly right-shifted: It contains a bit of unnecessary noise. But the effect *is* correct. > He did not require us to do any homework on it, so I don't have any > special tools in my notebooks. 30 years ago. Heh. The technology has > changed somewhat since then, but I recently read about some standard > encrypted sound files that were playable, noisy, but recognizable. > Same principle. It is very simple. The implementation is one page earlier in the document I sent you. If you replace i.e. AES-128-ECB with AES-128-OFB (and supply an initialization vector, which does not have such secrecy requirements as the key). -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709014205.gj114...@gwolf.org
Re: Debians security features in comparison to Ubuntu
Joel Rees dijo [Sat, May 17, 2014 at 10:06:41PM +0900]: > > The problem is, that Debian lacks a page similar to: > > https://wiki.ubuntu.com/Security/Features > > Is that page really useful? I mean, besides as a sort of sales brochure? Agree with this. It would be nice to have such a page, but having it means we'd have to remember to keep it up to date. And it provides little value but (precisely) being a sales brochure. So... :) > I did note that the debian pages on security are a bit dated. > > I suppose I should lend a hand there if I can find the time. How about > you, do you have the time? You don't have to start out understanding > the whole list, you just have to be willing to look up the debian > packages, learn how their setup works, and write down what you > learned, discuss it on the appropriate lists, then write up some > summaries and submit them. If you do good work, you'll be invited to > assume responsibility for some of the wiki pages. Right. And if the pages are generally seen as meaningful and well done, they might later become part of the "official" non-wiki webpage. > >> This will be an issue with any OS you > >> choose, even seriously secure OSses like openBSD. > > > > Is OpenBSD a seriously secure OS? > > I suppose it's easier to get into an openbsd server than it is to fly > to the moon, but if you set up an openbsd server and keep it updated, > attackers will generally find it easier to try social engineering > instead of attacking the server directly. > > Modulo the services you run, but that's true of any OS. If you are > running a hypertext protocol server and it has a hole, you have a hole > in your server. That last paragraph is, I found, the most important. Very few people run OpenBSD in its default install (other than for firewalls or similar stuff). Once you set up a webserver with dynamically generated content, a DBMS, and similar stuff... Well, you will find the "ports" (their term for our "packages") are not supported, and staying up to date is not as trivial as with Debian. OpenBSD is a *great* project and has contributed with many very important techniques. They have audited and improved many important packages (and the work they are currently doing with Open^WLibreSSL is just one such example). I would never say their work is not worth following. But as a sysadmin, many years ago I found Debian to be much preferrable — Because it cares about the overall security of a very large, very complex and wide-reaching set of programs, not just a core operating system around which to build whatever is needed. > > Last time I checked, OpenBSD didn't provide signed packages for the > > package manager by default. Using OpenBSD signed packages for updating > > only seemed ridiculously complicated. > > Basically, you're supposed to buy the CDs from the project. CDs are a > bit harder to spoof than dns, and they come out every six months. The CDs are a way to support (read: fund) the project. To keep your install up-to-date, you must download (unsigned!) patches from Internet, apply them to the tree and rebuild the needed parts of the OS. You are supposed to read the patches to understand what you are doing, although I'm certain many people don't — That's why I wrote an auto-patcher back in 2003 (http://gwolf.org/soft/tepatche/ — It's amazing how bitrot affects even my webpages :-| )... But yes, nowadays I'd be much more uneasy with fetching code from a given FTP server and pushing it automatically into my systems. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140517193308.ga4...@gwolf.org
Operation Windigo
I just wanted to share a *great* paper I'm currently reading, which describes the bone-chilling set of exploiting programs that has been talked about recently - A network of related tools to install and hide a credentials stealing infrastructure that, at least so far, has been mainly used to send spam. http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf Why is this paper of interest specifically to this list? - Debian is often mentioned in the examples. The reviewed daemons target multiple platforms, Debian among them. - Very thorough analysis. The paper will be a fun and welcome read to any security enthusiast. - Mitigation. Possibly, by better understanding the techniques used by the attackers, the Debian security team can avoid some of the pitfalls that led to its spread. Frankly, many of them look just like a collection of bugs leading to elevated access and regular sysadmin good practices (!), so I'm not sure too much can be done about them, but... You are the experts ;-) signature.asc Description: Digital signature
