Re: Support wifi-dongle Asus USB-N10 NANO in OpenBSD
On Fri, Jul 31, 2015 at 05:02:47AM +0500, ?? ?? wrote: > Is it supported? I mean exactly USB-N10 NANO, not USB-N10 I don't know specifically, but I've found from picking up pretty much at random cheapo 80211n USB warts (as in, inserted they're barely visible at all), a surprising number are in fact supported by the u*n drivers in OpenBSD. Your mileage may vary and in my experience the parts that claim ac compatibility are less likely to be supported at this point. The backstory is that the majority of these parts are simply rebadged parts sourced from a very limited number of manufacturers, and historically there has been little to no guarantee that parts with the exact same exterior attributes such as part number or type designation do not change internally to something quite different over time. So if the thing isn't terribly expensive, go buy it, stick it in an OpenBSD system and see if it comes up as something useful. Check -current too. If it isn't supported, consider tracking down a developer to send the part to. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Maintaining CAs not in cert.pem
On 2015-07-30 23:17, Stuart Henderson wrote: > On 2015-07-30, Vadim Zhukov wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : > cert.pem is pretty much a required file, we can't just move it to examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. > >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. There are for sure use cases (I've got several myself right off the bat) that would benefit from a simpler solution. Of course appending your own certs to the huge /etc/ssl/cert.pem file does work, but even with the assistance of sysmerge it is a clunky, potentially error prone maneuver... So I borrowed an idea from how the Courier MTA/IMAP/POP3 server manages some of its configuration files: The system could check whether /etc/ssl/cert.pem (or whatever path any particular application provides) is a regular file, in which case business as usual. But if it is a *directory* then LibreSSL would internally concatenate all of its contents (or, for example, just all *.pem files) when initializing the certificate chain. That "simple" mechanism would give the system administrator an application agnostic/transparent way to manage additions to the certificate store. I put simple within quotes though, because then I went into the source to see if I could quickly put together a proof of concept diff for discussion purposes... [ insert audience's laughter here ] To probably no ones surprise (including my own) I quickly gave up, realizing what an insanely complex piece of software it is! My head hurt just trying to follow along what was happening and who called what when why... I'm definitely not the right person to fiddle with that piece of code without some serious reading up, and of course any change made without a complete grasp of the entire library is almost certain to have unintended and potentially very serious side effects just about anywhere... So as I would only be doing everybody a disservice by providing code at this stage, I'm just throwing the idea out there for now. Is it a good idea or will it just confuse people and system? Is it even doable without breaking compatibility? If so, is it worth the effort? Regards, /Benny
Re: Maintaining CAs not in cert.pem
everyone on the carousel? why not rework the trust model.
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 09:17:23PM +, Stuart Henderson wrote: > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > If I remember correctly, the possibility of use SSL_CERT_FILE (from env) in libssl was been removed. So if the application don't let set a cafile (from argument, configfile...) libssl don't use another cert_file than /etc/ssl/cert.pem. -- Sebastien Marie
Re: Maintaining CAs not in cert.pem
this is a real problem for real people. On 2015 Jul 31 (Fri) at 02:33:00 +0300 (+0300), li...@wrant.com wrote: :Congrats to raising another time wasting topic for a public commentary. : -- Love thy neighbor as thyself, but choose your neighborhood. -- Louise Beal
Re: Maintaining CAs not in cert.pem
2015/07/31 9:15 "Joel Rees" : > > 2015/07/31 6:49 "Vadim Zhukov" : > > > > [...] > > > > > Well, I see four scenarios: > > > > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. > > > > 2. Use the defaults supplied with OpenBSD, and one or more additional > > CAs. Typical for corporate use. > > > > 3. Use personal set of CAs. Usually means either white-, or > > blacklisting entries from "base" certs pack. > > > > After more thinking I see that symlink idea is not good. But we can do > > some other thing: > > > > 1. Have "base" certs installed into /etc/examples/certs.pem. > > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > > 3. Have sysmerge handle certs specially: comparing not (old) > > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > > > What do you think? > > I know my opinions don't count much here, but it seems to me that mishandled certificates are such a huge cash cow that no one wants to do them right. Until the cash cow dies, anything we try now is likely to be wrong. > > With that caveat, try your ideas on your own system. You'll need to add some scripts of your own to extend what sysmerge and other tools do. Post to the list about how it works for you over the next year or so. > > That's my suggestion. I'm playing Don Quixote on list again. I did not mean that as an attack on Vadim, but it sure came out that way. My apologies to the list, and to Vadim. Joel Rees
Re: Maintaining CAs not in cert.pem
2015-07-31 3:15 GMT+03:00 Joel Rees : > 2015/07/31 6:49 "Vadim Zhukov" : >> >> [...] >> >> Well, I see four scenarios: >> >> 1. Using the defaults supplied with OpenBSD only. Typical for > home/personal use. >> >> 2. Use the defaults supplied with OpenBSD, and one or more additional >> CAs. Typical for corporate use. >> >> 3. Use personal set of CAs. Usually means either white-, or >> blacklisting entries from "base" certs pack. >> >> After more thinking I see that symlink idea is not good. But we can do >> some other thing: >> >> 1. Have "base" certs installed into /etc/examples/certs.pem. >> 2. Additional certs, if any, should go into /etc/ssl/local.pem. >> 3. Have sysmerge handle certs specially: comparing not (old) >> /etc/examples/cert.pem with /etc/ssl/cert.pem, but >> /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In >> case they do match, sysmerge would regenerate /etc/ssl/cert.pem by >> concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. >> >> What do you think? > > I know my opinions don't count much here, but it seems to me that > mishandled certificates are such a huge cash cow that no one wants to do > them right. Until the cash cow dies, anything we try now is likely to be > wrong. > > With that caveat, try your ideas on your own system. You'll need to add > some scripts of your own to extend what sysmerge and other tools do. Post > to the list about how it works for you over the next year or so. > > That's my suggestion. Discussed off-list. There was a misunderstanding that was (I hope) fixed. -- WBR, Vadim Zhukov
Re: Audio problems with OpenBSD-current/amd64 on Acer C720p Chromebook
Hi, after rebooting the GENERIC.MP kernel supplied with the 5.8 snapshot I had been using previously everything works fine. I don't actually know why -- I'll assume it was a hardware glitch. Sorry for wasting yout time. Best Regards, Alexander
Re: new (nasty) spam pattern
li...@wrant.com [li...@wrant.com] wrote: > > The spammers that he's talking about already handle greylisting, and > > they have SPF records, so you need to involve some kind of collaborative > > reporting system to block them quickly before they change colors again. > > closed or open community? It's a nude beach.
Re: 32bit vs. 64bit on older 64bit processors (fwd)
> probably more widely used by devs these days and so better tested too. 32bit system is alive, from the future, Ant.
Re: new (nasty) spam pattern
> The spammers that he's talking about already handle greylisting, and > they have SPF records, so you need to involve some kind of collaborative > reporting system to block them quickly before they change colors again. closed or open community?
Re: Maintaining CAs not in cert.pem
> mishandled certificates are such a huge cash cow that no one wants to do How is this related to OpenBSD?
Re: Maintaining CAs not in cert.pem
2015/07/31 6:49 "Vadim Zhukov" : > > [...] > > Well, I see four scenarios: > > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. > > 2. Use the defaults supplied with OpenBSD, and one or more additional > CAs. Typical for corporate use. > > 3. Use personal set of CAs. Usually means either white-, or > blacklisting entries from "base" certs pack. > > After more thinking I see that symlink idea is not good. But we can do > some other thing: > > 1. Have "base" certs installed into /etc/examples/certs.pem. > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > 3. Have sysmerge handle certs specially: comparing not (old) > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > What do you think? I know my opinions don't count much here, but it seems to me that mishandled certificates are such a huge cash cow that no one wants to do them right. Until the cash cow dies, anything we try now is likely to be wrong. With that caveat, try your ideas on your own system. You'll need to add some scripts of your own to extend what sysmerge and other tools do. Post to the list about how it works for you over the next year or so. That's my suggestion. Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Support wifi-dongle Asus USB-N10 NANO in OpenBSD
Is it supported? I mean exactly USB-N10 NANO, not USB-N10 Thanks.
Re: Maintaining CAs not in cert.pem
> > What do you think? Stop wasting time on this, there are more useful, reasonable and beautiful places to get lost.
Re: Maintaining CAs not in cert.pem
2015/07/31 8:34 : > > Congrats to raising another time wasting topic for a public commentary. > Do you mean that CAs, certificates, and how they are handled are topics that don't need talking about? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Audio problems with OpenBSD-current/amd64 on Acer C720p Chromebook
Gesendet: Donnerstag, 30. Juli 2015 um 23:27 Uhr Von: "Alexandre Ratchov" An: "Alexander Shendi" Cc: misc@openbsd.org Betreff: Re: Audio problems with OpenBSD-current/amd64 on Acer C720p Chromebook [snip] > could you do the following: build & install a new kernel with these > options defined. > > option AUDIO_DEBUG > option AZALIA_DEBUG > > Then, boot it, kill sndiod, and start it in a terminal with: > > sndiod -dd > > and in another terminal, play a .mp3 with mpg123 (or whatever you > use) and see what errors sndiod displays and what dmesg says. Let > me know if you have questions and/or you need help for the setup. > > thanks I did as you requested. Namely: * Got the OpenBSD-current sources via AnonCVS. * Built a custom kernel with the options above * Removed the "-f /dev/audio1" flags from /etc/rc.conf.local * Booted the new, custom kernel * Killed sndiod via "pkill sndiod" * Restarted it in a terminal as requested above * Played an MP3-file in VLC (no sound output observed) for a few seconds. Please find the combined terminal output and the new dmesg at: http://www.alexshendi.org/tmp/dmesg-acer-c720p-20150731.txt However I can't make much sense of the output as I don't know enough about the audio subsystem. Could you please have a look? Please let me know if I can run further test, or if you need further info. Many thanks for your help. Best Regards, Alexander
Re: Maintaining CAs not in cert.pem
2015-07-31 0:48 GMT+03:00 Vadim Zhukov : > 2015-07-31 0:17 GMT+03:00 Stuart Henderson : >> On 2015-07-30, Vadim Zhukov wrote: >>> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : On 2015-07-30, Ted Unangst wrote: > Michael McConville wrote: >> > Another meat could be, why you're using self-signed certificates? >> > Given the plethora of options for getting free (valid) certificates. >> >> He mentioned in his original email that it's a requirement where he >> works. That's common, from what I hear, although probably not the >> safest. > > I would consider a cert signed by somebody I actually trust (me) safer > than > delegating that trust to 300 strangers. I think cert.pem should move to the etc set, so you can remove CAs from the file (as well as add new ones) without risk of those changes getting reverted. Downside: CA changes will then only take effect after running sysmerge. Is that a problem? >>> >>> I think it is. This is the same as with /etc/examples: less stuff to >>> merge, less errors to happen. >> >> cert.pem is pretty much a required file, we can't just move it to examples/. >> For people who don't touch it, it's a simple no-touch sysmerge update. >> For people who do, having sysmerge ask about merging it is a lot safer >> than just overwriting. > > No, I didn't want to move /etc/ssl/cert.pem it to /etc/examples. I > think that its current contents could be provided in other way... > >>> I'd ask another question: why can't software use /etc/ssl/myown.pem, >>> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >>> "trust" and "untrust" operations as simple as possible. Noone in >>> healthy mind would place junk in /etc/ssl anyway, right? >> >> Some software allows you to set a different certificate file; other >> software doesn't. Patching everything in ports that verifies SSL certs >> to allow the user to specify an alternative file would just be insane. > > Hm-m, I always tried to live in a separate room with SSL beasts. Now I > realize that I saved a lot of nerves myself, and as a result I'm > living in a pink pony world. Thanks for getting back to the ground. > > I thought that there was some "default" in OpenSSL (and its > decendants) that programs tends to use. Now I realize there is no such > place. Okay, this variant gets busted. > >> And of course then there's no single way to tell programs to use the >> alternative file; "ftp -S cafile=/path/to/cert.pem", >> "env SSL_CERT_FILE=/path/to/cert.pem lynx" >> >>> Or we may ship /etc/ssl/base.pem in base tgz, and install >>> /etc/ssl/cert.pem -> base.pem at installation time. This way things >>> will work by default, and if you need to have your own trust path, you >>> just change symlink. What do you think? >> >> That doesn't really help. One common scenario is wanting to add a >> single CA to the standard file, but otherwise pick up updates (e.g. with >> sysmerge), this method doesn't allow that. > > Well, I see four scenarios: Those should be "three", of course. :) > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal > use. > > 2. Use the defaults supplied with OpenBSD, and one or more additional > CAs. Typical for corporate use. > > 3. Use personal set of CAs. Usually means either white-, or > blacklisting entries from "base" certs pack. > > After more thinking I see that symlink idea is not good. But we can do > some other thing: > > 1. Have "base" certs installed into /etc/examples/certs.pem. > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > 3. Have sysmerge handle certs specially: comparing not (old) > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > What do you think? -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
Congrats to raising another time wasting topic for a public commentary.
Re: Intel Atom?
> >yet the original poster is > > obviously looking for COTS consumer electronics general purpose > > inexpensive mini-ITX mainboards for home router project. > > Off-the-shelf yes, home no, it's just a specialized setup with some odd > requirements. We're fine with paying for good quality components but > there's no need to overpay for something that offers a bunch of stuff we > don't need, especially when we're going to be building several of these. > I'm just trying to find the best balance, and I'm hoping that > upper-mid-range Atoms are where it's at. Well, did you solve it? What's your useful idea to bring to other readers? Do you have any experience related to this that we would like to read on? Jumping topics like a recently released person, hopefully you were not wasting everybody's time on the list.
Re: OpenBSD httpd version
The sooner people know they are dealing with OpenBSD the sooner they give up and look for a softer target. On Thu, Jul 30, 2015, at 08:11 AM, averl...@nextmail.ru wrote: > Hi All. > > How do I hide OpenBSD webserver name info from clients? > I do not want to show the world what operating system and web server is > used. > > So I made a few changes on the 5.7-stable. > > [demime 1.01d removed an attachment of type text/x-diff which had a name > of httpd.patch]
Re: new (nasty) spam pattern
On 30/07/2015 16:09, Seth wrote: Steve, I had the some problem, lots of spammers were figuring out how to 'climb over the greywall', so I added spamd-bpgd [1] and a few blacklists [2] into the mix. I haven't figure out how to incorporate DNSBL into spamd, so I use the cruder method of downloading the blacklists every 20 minutes via ftp or rsync and a cronjob. I also found a post in the mailing list archives which describes how to use greyscanner to trap any mailservers sending to addresses with numbers in them. [3] (hat tip to Joakim Aronius) Oooh, nice. Some meat there for me to look into. Thanks. Meanwhile, my database of sinners really should be "out there" to ... But where? I update it several times a day... Steve (PS: went after one of the main spammers - nice house in New Jersey. We have a rep in the USA... non-violent suggestions for retribution? -- -- Steve Fairhead fivetrees ltd - for the complete music service email: st...@fivetrees.com www: http://www.fivetrees.com --
Re: rdomain with BGP dynamic route
On 07/30/2015 10:26 AM, XU, YANG (YANG) wrote: Adam, Your comments and links are very helpful, they made some concepts clear for me. Many thanks! What I need essentially is VRF function which converts IPv4 prefix to VPNv4 prefix dynamically. I hope experts can help on this. After spending so much time on searching for the answer, sending beer is an easier thing to do. Just give me a working example, and beer will be on the way :) Regards, -Yang After that clarification, I understand even less than I did before of what you want to accomplish. Regardless, at this point I'd say your options for continuing with OpenBSD might be limited to: a) go to one of the BSD conferences, locate one of the developers who work on the network stack [this isn't very hard], and ask them; or b) pay someone (e.g. maybe reyk@ et al. over at Esdenera Networks, not sure who else would be a candidate) to figure it out for you and, if necessary, fix it. -Adam
Re: OpenBSD vs Notebook Speaker.
> > I'd start with the ones named "Master" because of reasons. > > "Because of reasons" just became my favourite argument, thanks. As if "The" subject is not hilarious enough? The verdammte master control unit operating system versus the computer controlled electric-acoustic transducer... What a great battle, no wait it's a comparison.
Re: Maintaining CAs not in cert.pem
2015-07-31 0:17 GMT+03:00 Stuart Henderson : > On 2015-07-30, Vadim Zhukov wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : >>> On 2015-07-30, Ted Unangst wrote: Michael McConville wrote: > > Another meat could be, why you're using self-signed certificates? > > Given the plethora of options for getting free (valid) certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. I would consider a cert signed by somebody I actually trust (me) safer than delegating that trust to 300 strangers. >>> >>> I think cert.pem should move to the etc set, so you can remove >>> CAs from the file (as well as add new ones) without risk of those >>> changes getting reverted. >>> >>> Downside: CA changes will then only take effect after running >>> sysmerge. Is that a problem? >> >> I think it is. This is the same as with /etc/examples: less stuff to >> merge, less errors to happen. > > cert.pem is pretty much a required file, we can't just move it to examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. No, I didn't want to move /etc/ssl/cert.pem it to /etc/examples. I think that its current contents could be provided in other way... >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. Hm-m, I always tried to live in a separate room with SSL beasts. Now I realize that I saved a lot of nerves myself, and as a result I'm living in a pink pony world. Thanks for getting back to the ground. I thought that there was some "default" in OpenSSL (and its decendants) that programs tends to use. Now I realize there is no such place. Okay, this variant gets busted. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. Well, I see four scenarios: 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. 2. Use the defaults supplied with OpenBSD, and one or more additional CAs. Typical for corporate use. 3. Use personal set of CAs. Usually means either white-, or blacklisting entries from "base" certs pack. After more thinking I see that symlink idea is not good. But we can do some other thing: 1. Have "base" certs installed into /etc/examples/certs.pem. 2. Additional certs, if any, should go into /etc/ssl/local.pem. 3. Have sysmerge handle certs specially: comparing not (old) /etc/examples/cert.pem with /etc/ssl/cert.pem, but /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In case they do match, sysmerge would regenerate /etc/ssl/cert.pem by concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. What do you think? -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
On Thu, July 30, 2015 5:17 pm, Stuart Henderson wrote: > On 2015-07-30, Vadim Zhukov wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson : >>> On 2015-07-30, Ted Unangst wrote: Michael McConville wrote: > > Another meat could be, why you're using self-signed certificates? > > Given the plethora of options for getting free (valid) > certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. I would consider a cert signed by somebody I actually trust (me) safer than delegating that trust to 300 strangers. >>> >>> I think cert.pem should move to the etc set, so you can remove >>> CAs from the file (as well as add new ones) without risk of those >>> changes getting reverted. >>> >>> Downside: CA changes will then only take effect after running >>> sysmerge. Is that a problem? >> >> I think it is. This is the same as with /etc/examples: less stuff to >> merge, less errors to happen. > > cert.pem is pretty much a required file, we can't just move it to > examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting. > >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. > Well I didn't expect this to take off into larger conversation... :) Work requirements aside, for personal use, I prefer to use my own CA over self signed certificates because I can manage that centrally. I don't have to tell applications to allow self-signed certs which might apply to all domains and not just my own, or respond to warnings about them. Also it's more fail-safe. If I forget to re-add my CA (or use sysmerge if we go that way) then I'll see warnings or errors I won't be expecting. I initially though cert.pem was managed by sysmerge. That would be a solution I think would work well. Tim.
Re: Audio problems with OpenBSD-current/amd64 on Acer C720p Chromebook
On Thu, Jul 30, 2015 at 09:29:31PM +0200, Alexander Shendi wrote: > Dear list subscribers, > > I have installed OpenBSD-current on my Acer C720p Chromebook. > I am using -current because I had problems with X11 with > the 5.7 release. > > Audio used to work out of the box on that device with earlier > versions of -current, but has stopped working in the most recent > version I have installed (Playback of an MP3-file with either > VLC or mpg123 produced no sound) > > $ uname -a > OpenBSD alex-acer-720p.my.domain 5.8 GENERIC.MP#1206 amd64 > > Excerpt from dmesg follows: > > [...] > azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi > azalia0: No codecs found > [...] > azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi > azalia1: codecs: Realtek/0x0283 > audio0 at azalia1 > [...] > > (The entire dmesg can be found at: > http://www.alexshendi.org/tmp/dmesg-c720p-20150730.txt) > > However I had some success in getting sound to work: I added the line: > > sndiod_flags='-f /dev/audio1' > > to /etc/rc.conf.local > there's no /dev/audio1 according to your dmesg and -f uses another syntax (see sndio(7) man page) > Now playing an MP3-file in VLC works, but I'm not able to adjust the volume > in VLC. Does this have something to do with /dev/audioctl? > > I noticed that both /dev/audio and /dev/audioctl are symlinks to > /dev/audio0 resp. /dev/audioctl0. Sould I change these links > to point to audio1 and audioctl1? The symlinks are only used by audioctl and mixerctl utilities, no need to change them. > > Any suggestions will be appreciated. Many thanks in advance. could you do the following: build & install a new kernel with these options defined. option AUDIO_DEBUG option AZALIA_DEBUG Then, boot it, kill sndiod, and start it in a terminal with: sndiod -dd and in another terminal, play a .mp3 with mpg123 (or whatever you use) and see what errors sndiod displays and what dmesg says. Let me know if you have questions and/or you need help for the setup. thanks
Re: Maintaining CAs not in cert.pem
On 2015-07-30, Vadim Zhukov wrote: > 2015-07-30 20:16 GMT+03:00 Stuart Henderson : >> On 2015-07-30, Ted Unangst wrote: >>> Michael McConville wrote: > Another meat could be, why you're using self-signed certificates? > Given the plethora of options for getting free (valid) certificates. He mentioned in his original email that it's a requirement where he works. That's common, from what I hear, although probably not the safest. >>> >>> I would consider a cert signed by somebody I actually trust (me) safer than >>> delegating that trust to 300 strangers. >> >> I think cert.pem should move to the etc set, so you can remove >> CAs from the file (as well as add new ones) without risk of those >> changes getting reverted. >> >> Downside: CA changes will then only take effect after running >> sysmerge. Is that a problem? > > I think it is. This is the same as with /etc/examples: less stuff to > merge, less errors to happen. cert.pem is pretty much a required file, we can't just move it to examples/. For people who don't touch it, it's a simple no-touch sysmerge update. For people who do, having sysmerge ask about merging it is a lot safer than just overwriting. > I'd ask another question: why can't software use /etc/ssl/myown.pem, > or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make > "trust" and "untrust" operations as simple as possible. Noone in > healthy mind would place junk in /etc/ssl anyway, right? Some software allows you to set a different certificate file; other software doesn't. Patching everything in ports that verifies SSL certs to allow the user to specify an alternative file would just be insane. And of course then there's no single way to tell programs to use the alternative file; "ftp -S cafile=/path/to/cert.pem", "env SSL_CERT_FILE=/path/to/cert.pem lynx" > Or we may ship /etc/ssl/base.pem in base tgz, and install > /etc/ssl/cert.pem -> base.pem at installation time. This way things > will work by default, and if you need to have your own trust path, you > just change symlink. What do you think? That doesn't really help. One common scenario is wanting to add a single CA to the standard file, but otherwise pick up updates (e.g. with sysmerge), this method doesn't allow that.
Audio problems with OpenBSD-current/amd64 on Acer C720p Chromebook
Dear list subscribers, I have installed OpenBSD-current on my Acer C720p Chromebook. I am using -current because I had problems with X11 with the 5.7 release. Audio used to work out of the box on that device with earlier versions of -current, but has stopped working in the most recent version I have installed (Playback of an MP3-file with either VLC or mpg123 produced no sound) $ uname -a OpenBSD alex-acer-720p.my.domain 5.8 GENERIC.MP#1206 amd64 Excerpt from dmesg follows: [...] azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi azalia0: No codecs found [...] azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi azalia1: codecs: Realtek/0x0283 audio0 at azalia1 [...] (The entire dmesg can be found at: http://www.alexshendi.org/tmp/dmesg-c720p-20150730.txt) However I had some success in getting sound to work: I added the line: sndiod_flags='-f /dev/audio1' to /etc/rc.conf.local Now playing an MP3-file in VLC works, but I'm not able to adjust the volume in VLC. Does this have something to do with /dev/audioctl? I noticed that both /dev/audio and /dev/audioctl are symlinks to /dev/audio0 resp. /dev/audioctl0. Sould I change these links to point to audio1 and audioctl1? Any suggestions will be appreciated. Many thanks in advance. Best Regards, Alexander
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 05:16:30PM +, Stuart Henderson wrote: > On 2015-07-30, Ted Unangst wrote: > > Michael McConville wrote: > >> > Another meat could be, why you're using self-signed certificates? > >> > Given the plethora of options for getting free (valid) certificates. > >> > >> He mentioned in his original email that it's a requirement where he > >> works. That's common, from what I hear, although probably not the > >> safest. > > > > I would consider a cert signed by somebody I actually trust (me) safer than > > delegating that trust to 300 strangers. > > I think cert.pem should move to the etc set, so you can remove > CAs from the file (as well as add new ones) without risk of those > changes getting reverted. > > Downside: CA changes will then only take effect after running > sysmerge. Is that a problem? I would like to see cert.pm become a "managed" file. FWIW OK rpe@ -- -=[rpe]=-
Re: Maintaining CAs not in cert.pem
2015-07-30 20:16 GMT+03:00 Stuart Henderson : > On 2015-07-30, Ted Unangst wrote: >> Michael McConville wrote: >>> > Another meat could be, why you're using self-signed certificates? >>> > Given the plethora of options for getting free (valid) certificates. >>> >>> He mentioned in his original email that it's a requirement where he >>> works. That's common, from what I hear, although probably not the >>> safest. >> >> I would consider a cert signed by somebody I actually trust (me) safer than >> delegating that trust to 300 strangers. > > I think cert.pem should move to the etc set, so you can remove > CAs from the file (as well as add new ones) without risk of those > changes getting reverted. > > Downside: CA changes will then only take effect after running > sysmerge. Is that a problem? I think it is. This is the same as with /etc/examples: less stuff to merge, less errors to happen. I'd ask another question: why can't software use /etc/ssl/myown.pem, or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make "trust" and "untrust" operations as simple as possible. Noone in healthy mind would place junk in /etc/ssl anyway, right? Or we may ship /etc/ssl/base.pem in base tgz, and install /etc/ssl/cert.pem -> base.pem at installation time. This way things will work by default, and if you need to have your own trust path, you just change symlink. What do you think? > Index: base/mi > === > RCS file: /cvs/src/distrib/sets/lists/base/mi,v > retrieving revision 1.716 > diff -u -p -r1.716 mi > --- base/mi 16 Jul 2015 21:28:06 - 1.716 > +++ base/mi 30 Jul 2015 17:14:15 - > @@ -221,7 +221,6 @@ > ./etc/skel/.ssh > ./etc/ssh > ./etc/ssl > -./etc/ssl/cert.pem > ./etc/ssl/lib > ./etc/ssl/private > ./etc/systrace > Index: etc/mi > === > RCS file: /cvs/src/distrib/sets/lists/etc/mi,v > retrieving revision 1.199 > diff -u -p -r1.199 mi > --- etc/mi 3 Jul 2015 22:52:52 - 1.199 > +++ etc/mi 30 Jul 2015 17:14:15 - > @@ -42,6 +42,7 @@ > ./etc/spwd.db > ./etc/ssh/ssh_config > ./etc/ssh/sshd_config > +./etc/ssl/cert.pem > ./etc/ssl/openssl.cnf > ./etc/ssl/x509v3.cnf > ./etc/syslog.conf -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
Stuart Henderson wrote: > On 2015-07-30, Ted Unangst wrote: > > Michael McConville wrote: > >> > Another meat could be, why you're using self-signed certificates? > >> > Given the plethora of options for getting free (valid) certificates. > >> > >> He mentioned in his original email that it's a requirement where he > >> works. That's common, from what I hear, although probably not the > >> safest. > > > > I would consider a cert signed by somebody I actually trust (me) safer than > > delegating that trust to 300 strangers. > > I think cert.pem should move to the etc set, so you can remove > CAs from the file (as well as add new ones) without risk of those > changes getting reverted. > > Downside: CA changes will then only take effect after running > sysmerge. Is that a problem? Not in my mind. I'm all for this; it's outside my department or I would have suggested the same.
Re: Maintaining CAs not in cert.pem
On 2015-07-30, Ted Unangst wrote: > Michael McConville wrote: >> > Another meat could be, why you're using self-signed certificates? >> > Given the plethora of options for getting free (valid) certificates. >> >> He mentioned in his original email that it's a requirement where he >> works. That's common, from what I hear, although probably not the >> safest. > > I would consider a cert signed by somebody I actually trust (me) safer than > delegating that trust to 300 strangers. I think cert.pem should move to the etc set, so you can remove CAs from the file (as well as add new ones) without risk of those changes getting reverted. Downside: CA changes will then only take effect after running sysmerge. Is that a problem? Index: base/mi === RCS file: /cvs/src/distrib/sets/lists/base/mi,v retrieving revision 1.716 diff -u -p -r1.716 mi --- base/mi 16 Jul 2015 21:28:06 - 1.716 +++ base/mi 30 Jul 2015 17:14:15 - @@ -221,7 +221,6 @@ ./etc/skel/.ssh ./etc/ssh ./etc/ssl -./etc/ssl/cert.pem ./etc/ssl/lib ./etc/ssl/private ./etc/systrace Index: etc/mi === RCS file: /cvs/src/distrib/sets/lists/etc/mi,v retrieving revision 1.199 diff -u -p -r1.199 mi --- etc/mi 3 Jul 2015 22:52:52 - 1.199 +++ etc/mi 30 Jul 2015 17:14:15 - @@ -42,6 +42,7 @@ ./etc/spwd.db ./etc/ssh/ssh_config ./etc/ssh/sshd_config +./etc/ssl/cert.pem ./etc/ssl/openssl.cnf ./etc/ssl/x509v3.cnf ./etc/syslog.conf
Re: new (nasty) spam pattern
On 07/30/2015 11:14 AM, Seth wrote: On Thu, 30 Jul 2015 08:09:38 -0700, Seth wrote: Sorry, forgot the link to greyscanner post [3] http://www.mail-archive.com/misc@openbsd.org/msg116961.html DNSBL is very powerful: post:gwes:4612$ grep -c listed /var/log/maillog 501 post:gwes:grep -c -n sent /var/log/maillog 7 I have to run sendmail until spamd or smtpd can do DNSBL No other solution works nearly as well.
Re: Maintaining CAs not in cert.pem
Em 30-07-2015 13:58, Kimmo Paasiala escreveu: > That depends on the use case of the certificate. Use of self-signed > certificate is no less secure than an "official" one as far as the > actual encryption on the transport layer goes. It's only a question if > the user trusts the authenticity of the self-signed certificate and > the issuer of certificate is prepared to educate his/her users what a > self-signed certificate is and why they should trust it. Yes, self-signed certs have their uses. VPN's come to mind. Custom CA's for intercepting, also. Since most people don't even care about tls warnings, they got their uses. But, as it is becoming clearer and clearer to the OP, you need to maintain it yourself, and not screw up. Cheers, Giancarlo Razzolini
Re: Maintaining CAs not in cert.pem
Ted Unangst wrote: > Michael McConville wrote: > > > Another meat could be, why you're using self-signed certificates? > > > Given the plethora of options for getting free (valid) certificates. > > > > He mentioned in his original email that it's a requirement where he > > works. That's common, from what I hear, although probably not the > > safest. > > I would consider a cert signed by somebody I actually trust (me) safer > than delegating that trust to 300 strangers. I was thinking of offices that make employees install their root certificate so that their encrypted traffic can be filtered/monitored.
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 7:47 PM, Michael McConville wrote: > Giancarlo Razzolini wrote: >> Em 30-07-2015 09:15, trondd escreveu: >> > I guess the meat of the question is "is certs.pem the only location >> > for CAs used by the system?" (ignoring application certificate >> > stores, ie. Firefox or java). >> >> Another meat could be, why you're using self-signed certificates? >> Given the plethora of options for getting free (valid) certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. > That depends on the use case of the certificate. Use of self-signed certificate is no less secure than an "official" one as far as the actual encryption on the transport layer goes. It's only a question if the user trusts the authenticity of the self-signed certificate and the issuer of certificate is prepared to educate his/her users what a self-signed certificate is and why they should trust it. -Kimmo
Re: Maintaining CAs not in cert.pem
Michael McConville wrote: > > Another meat could be, why you're using self-signed certificates? > > Given the plethora of options for getting free (valid) certificates. > > He mentioned in his original email that it's a requirement where he > works. That's common, from what I hear, although probably not the > safest. I would consider a cert signed by somebody I actually trust (me) safer than delegating that trust to 300 strangers.
Re: Maintaining CAs not in cert.pem
Giancarlo Razzolini wrote: > Em 30-07-2015 09:15, trondd escreveu: > > I guess the meat of the question is "is certs.pem the only location > > for CAs used by the system?" (ignoring application certificate > > stores, ie. Firefox or java). > > Another meat could be, why you're using self-signed certificates? > Given the plethora of options for getting free (valid) certificates. He mentioned in his original email that it's a requirement where he works. That's common, from what I hear, although probably not the safest.
Re: Maintaining CAs not in cert.pem
Em 30-07-2015 09:15, trondd escreveu: > I guess the meat of the question is "is certs.pem the only location for > CAs used by the system?" (ignoring application certificate stores, ie. > Firefox or java). Another meat could be, why you're using self-signed certificates? Given the plethora of options for getting free (valid) certificates. Cheers, Giancarlo Razzolini
Re: rdomain with BGP dynamic route
Adam,
Your comments and links are very helpful, they made some concepts clear for
me. Many thanks!
What I need essentially is VRF function which converts IPv4 prefix to VPNv4
prefix dynamically. I hope experts can help on this. After spending so much
time on searching for the answer, sending beer is an easier thing to do. Just
give me a working example, and beer will be on the way :)
Regards,
-Yang
-Original Message-
From: Adam Thompson [mailto:athom...@athompso.net]
Sent: Tuesday, July 28, 2015 8:59 PM
To: XU, YANG (YANG)
Cc: misc@openbsd.org
Subject: Re: rdomain with BGP dynamic route
I see what you mean.
This, I think, is close to what you're looking for, but I'm not 100% certain of
how to accomplish exactly what you want:
nexthop qualify via bgp
listen on A.B.C.D ## vrf member address of, say, em1
rtable 2 ## put vrf interface into rdomain 2 via ifconfig?
rdomain 2 {
rd 123:456
depend on em1
}
neighbor VPNCLIENT1 {
depend on em1
}
...I don't know how to avoid running a separate instance of bgpd(8) per VRF,
however.
Given that OpenBSD has, apparently, a working MPLS + LDP implementation, this
is obviously yet another case where the manual pages contain enough information
Based on jeker's MPLS paper back at EuroBSDCon 2011, it may be the case that
BGP + VRF really only works work mpe(4).
Ah! I found someone else's documentation that explains it... you do still need
to use rdomain0, but you MUST tag the routes. rdomain0 contains everything,
including the [possibly overlapping] routes, but with prefixes to keep them
separate.
See http://firstyear.id.au/entry/21. Also see jeker's explanation (perhaps
dated) here:
http://openbsd-archive.7691.n7.nabble.com/Using-RDomain-setup-with-pf-4-and-bgpd-8-td42066.html.
(Also check out http://lmgtfy.com/?q=openbsd+bgp+vrf. Admittedly, the fourth or
fifth result _is_ this thread :-/.)
Failing that, as I can't tell for certain if it does what you want, wait for
Claudio, Henning, or whoever else is working on it now to figure out how to
make it work better! I hear sending them beer sometimes helps...
-Adam
On 07/24/2015 08:07 PM, XU, YANG (YANG) wrote:
> Adam,
>
> I really appreciate your reply. I read bgpd.conf and see rdomain can only
> define network as explicit, static or connected. In my case, I need to import
> dynamic prefix from BGP session. Right now all prefix learned from BGP goes
> to rdomain 0. I want to put prefix learned from BGP into the rdomain I
> specify.
>
> Thanks,
> -Yang
>
> From: Adam Thompson [athom...@athompso.net]
> Sent: 24 July 2015 20:33
> To: XU, YANG (YANG)
> Subject: Re: rdomain with BGP dynamic route
>
> On 2015-07-24 06:47 AM, XU, YANG (YANG) wrote:
>> Let me describe it in another way. Can I create a new rdomain as a VRF and
>> use the rdomain to import/export customer's prefix through BGP?
>>
>> I will greatly appreciate it if you can provide any information. I have seen
>> some information online, but prefix is either from static configuration or
>> connected network. In my case, I need to support dynamic routes from BGP in
>> VRF.
> Short answer: yes.
>
> See man bgpd.conf(5):
>
> ROUTING DOMAIN CONFIGURATION
> bgpd(8) supports the setup and distribution of Virtual Private Networks.
> It is possible to import and export prefixes between routing domains.
> Each routing domain is specified by an rdomain section, which allows
> properties to be set specifically for that rdomain:
> rdomain 1 {
> descr "a rdomain"
> rd 65002:1
> import-target rt 65002:42
> export-target rt 65002:42
> network 192.168.1/24
> depend on mpe0
> }
>
> --
> -Adam Thompson
>athom...@athompso.net
Re: new (nasty) spam pattern
On Wed, 29 Jul 2015 15:12:17 -0700, Steve Fairhead wrote> But when it does, I'd like to hurt them. I also run spamd; can't seem to find a way to tarpit based on domain rather than IP... Any cluebats? Steve, I had the some problem, lots of spammers were figuring out how to 'climb over the greywall', so I added spamd-bpgd [1] and a few blacklists [2] into the mix. I haven't figure out how to incorporate DNSBL into spamd, so I use the cruder method of downloading the blacklists every 20 minutes via ftp or rsync and a cronjob. I also found a post in the mailing list archives which describes how to use greyscanner to trap any mailservers sending to addresses with numbers in them. [3] (hat tip to Joakim Aronius) /etc/mail/spamd.conf all:\ :bgp-spamd:spammers:lashback:blocklist-de:psbl: bgp-spamd:\ :black:\ :msg="Your address %A has sent mail to a spamtrap\n\ within the last 24 hours":\ :method=file:\ :file=/etc/mail/bgp-spamd.black: spammers:\ :black:\ :msg="Your address %A has sent spam\n\ within the last 24 hours":\ :method=file:\ :file=/etc/mail/spammers.black: lashback:\ :black:\ :msg="Your address %A has been sending email to\n\ names harvested from suppression files":\ :method=file:\ :file=/etc/mail/lashback.black: blocklist-de:\ :black:\ :msg="Your address %A has been reported within\n\ the last 48 hours as having run attacks on mail servers":\ :method=file:\ :file=/etc/mail/blocklist-de.black: psbl:\ :black:\ :msg="Your address %A has been reported to the\n\ passive spam block list psbl.org":\ :method=file:\ :file=/etc/mail/psbl.black: # crontab -l # update bgp-spamd blacklist 20 * * * * /usr/local/sbin/bgp-spamd.black.sh # update lashback blacklist every 20 minutes 20 * * * * ftp -o /etc/mail/lashback.black http://www.unsubscore.com/blacklist.txt && /usr/libexec/spamd-setup # update blocklist-de blacklist every 20 minutes 20 * * * * ftp -o /etc/mail/blocklist-de.black https://lists.blocklist.de/lists/mail.txt && /usr/libexec/spamd-setup # update passive spam block list every 20 minutes 20 * * * * /usr/local/bin/rsync -z psbl-mirror.surriel.com::psbl/psbl.txt /etc/mail/psbl.black && /usr/libexec/spamd-setup [1] http://bgp-spamd.net/ [2] https://mxtoolbox.com/blacklists.aspx [3]
Re: new (nasty) spam pattern
On Thu, 30 Jul 2015 08:09:38 -0700, Seth wrote: Sorry, forgot the link to greyscanner post [3] http://www.mail-archive.com/misc@openbsd.org/msg116961.html
Re: OpenBSD httpd version
http://sebsauvage.net/paste/?d626887c11c71990#gbO8qudKQ4LXoAuLGC5zYd6CnEqdNlJzf9lGAZ3pO5U=
newfs_ext2fs vs e2fsprogs package mke2fs
Which is preferred, newfs_ext2fs or mke2fs from the e2fsprogs package? Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
OpenBSD httpd version
Hi All. How do I hide OpenBSD webserver name info from clients? I do not want to show the world what operating system and web server is used. So I made a few changes on the 5.7-stable. [demime 1.01d removed an attachment of type text/x-diff which had a name of httpd.patch]
Re: Maintaining CAs not in cert.pem
2015-07-30 3:02 GMT+03:00 trondd : > I have my own CA for home use and my work also has their own CA and > intermediate certificates. What is the correct way of maintaining the > certificates so that the system always knows about them? I've been > appending them to /etc/ssl/cert.pem but it gets replaced every update (not > even maintained with sysmerge since it comes for libcrypto and not the etc > package). > > Is there a place to put them that is automatically read in addition to > cert.pem? It depends on software you're using, actually. Qt 4 and 5 look at the whole /etc/ssl (without subdirs) for certificates, for example. -- WBR, Vadim Zhukov
Re: Maintaining CAs not in cert.pem
On Thu, July 30, 2015 4:13 am, Raf Czlonka wrote: > > Why now simply put it in siteXX.tgz? > >> Tim. > > Raf > I guess the meat of the question is "is certs.pem the only location for CAs used by the system?" (ignoring application certificate stores, ie. Firefox or java). I guess tweaking my upgrade processes/scripts isn't that hard if everything has to be in certs.pem. Just don't want to go in that direction if there is an alternative already built in. Tim.
Re: new (nasty) spam pattern
Hi Steve, On 2015-07-29 Wed 23:12 PM |, Steve Fairhead wrote: > > Am now seeing a recent (last few months) HEEEUUGE increase in spam to my > (redirected mail) users with the following pattern: > > - spam sent to many email addresses with one-time-only domain, each of > which has a barely traceable and mobile (and maybe temporary) IP, but with a > whois record going back to a few repeating registrants (Batista Network, > WhoisGuard in Panama, MXSPORT LLC, SHOUTMEDIA INC. being a few of several). They're probably spamming many others too. Consider giving DNSBL a try: http://en.wikipedia.org/wiki/DNSBL http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists I've found these (in this order) effective: psbl.surriel.com dnsbl-1.uceprotect.net dnsbl.sorbs.net zen.spamhaus.org > > I'm not sure I can do better than what I do now: record the domains (or > email patterns) to a database, from which I derive an access db for > sendmail, and reject them with a fairly polite message - which doesn't > happen often. > > But when it does, I'd like to hurt them. I also run spamd; can't seem to > find a way to tarpit based on domain rather than IP... > Most MTAs can use DNS back lists, but I've found a fast & low overhead way to do it is to check spamdb's GREYs & trap if DNS black listed. Then they get hurt by spamd & can't hammer the MTA. > Any cluebats? pkg_add greyscanner Cheers -- Scottish folk dancing in Linlithgow Palace ruins to live bands: http://www.ScotchHop.Org.UK/Pictures.html https://www.facebook.com/linlithgowscotchhop/photos_stream
Re: Maintaining CAs not in cert.pem
On Thu, Jul 30, 2015 at 01:02:52AM BST, trondd wrote: > I have my own CA for home use and my work also has their own CA and > intermediate certificates. What is the correct way of maintaining the > certificates so that the system always knows about them? I've been > appending them to /etc/ssl/cert.pem but it gets replaced every update > (not even maintained with sysmerge since it comes for libcrypto and > not the etc package). > > Is there a place to put them that is automatically read in addition to > cert.pem? Why now simply put it in siteXX.tgz? > Tim. Raf
