You completely misunderstand what "be liberal in what you accept" means.
It doesn't mean to take any input and cherrypick single bits that you understand and ignore the rest. You rather try to parse inputs liberally, while making sure it's unambiguous in its meaning. For example, when parsing a config file, there could be more whitespace than necessary. As long as you find valid keywords in that extra whitespace, you're good to parse it liberally. When writing a config file, however, you're supposed to trim all that whitespace to a uniform scheme.
You would also be free to ignore invalid keywords to support forward compatibility.
What you shouldn't do and what being liberal doesn't mean is saying "this input would be correct to me if I threw away these letters in the keyword". That's just retarded.
What they should and should not do can be easily found out by looking at your contract. And that's the end of the story. If you want free market, act like a responsible market participant.
Then it's not just a modem. Do you have a separate router or just your "modem"?
If you have a router, then you're doing an unnecessary double-router setup. If you don't, then the whole point is moot. A modem is transparent to layer 3 and provides a common layer 2 among different layer 1s.
The (separate) router on the LAN side of the modem needs to be aware of the 192.168.100/24 on its WAN side or else it won't know how to reach it on layer 3, regardless of every traffic passing thourgh the modem on layer 2.
If you use 10/8 internally, then your router will either forward packets for 192.168.100.1 to your ISP or drop them entirely. What makes you think just putting a device with 192.168.100.1 on the WAN side of your router makes it reachable if your router doesn't know anything about 192.168.100/24 on that interface?
Seriously, get a clue about networking and routing.
If the modem is using an RFC1918 address and is sitting on the WAN side of the router and the router is blocking RFC1918 on its WAN interface, what do you think will happen?
Maybe you should think more or stop posting about topics you don't understand.
Free certs technically are exactly the same as every other cert. What you probably mean is to choose a higher validation than DV. That's the only reason you should pay someone money. But that has nothing to do with which devices accept your cert. That is a matter of server config and how you configure your TLS algorithms.
The point is, when that thing is still running, what prevents the Internet service you're using from switchting it into recording state remotely? Just because it doesn't transmit data "right now", doesn't mean it can't be made to, remotely.
However, that's exactly the reason why I wouldn't use anything "cloud" in the first place. Give me a cam that can upload to my server. I don't care if it's really off or not, if I can firewall it to only talk to my services.
As such, this "problem" is only a problem because it highlights the bad decision someone made in the first place, namely using "cloud-based" bullshit.
Simple, the username is to be considered public knowledge. It's visible when entering it everywhere, it may be in ~/.ssh/config, it's not a secret.
Just assume the whole world knows it already. All strength must come from the password either way, so don't even start to treat the username as some sort of secret.
Whether there's someone sitting on your line and grabbing your traffic or tampering with it is completely irrelevant because that problem exists in any case. By running your own resolver, you don't publish your queries directly to a third party on top of that and that's a good thing.
That's what you get when offering VPN access must include proper client configs because users are clueless and want to be "secure" by hitting a button.
I guarantee you that I could take the credentials of each and every one of these VPN offers, put them into my router and tunnel all my clients properly(!) without any leaks.
It's not the VPN that is flawed, it's the CLIENT SETUP. For people with a clue, that's a distinction.
When it comes to IT, I'll gladly let the hipsters deal with the pain and the data loss for a 0.5% speedup and use whatever they came up with - and is still relevant - after 10 years. Thank you very much.
009: SECURITY FIX: June 11, 2015 All architectures Fix several defects from OpenSSL:
CVE-2015-1788 - Malformed ECParameters causes infinite loop
CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time
CVE-2015-1792 - CMS verify infinite loop with unknown hash function
Note that CMS was already disabled in LibreSSL. Several other issues did not apply or were already fixed and one is under review. For more information, see the OpenSSL advisory. A source code patch exists which remedies this problem.
Slashdot Mirror
Yes, you could terminate your regular expressions.
You completely misunderstand what "be liberal in what you accept" means.
It doesn't mean to take any input and cherrypick single bits that you understand and ignore the rest. You rather try to parse inputs liberally, while making sure it's unambiguous in its meaning. For example, when parsing a config file, there could be more whitespace than necessary. As long as you find valid keywords in that extra whitespace, you're good to parse it liberally. When writing a config file, however, you're supposed to trim all that whitespace to a uniform scheme.
You would also be free to ignore invalid keywords to support forward compatibility.
What you shouldn't do and what being liberal doesn't mean is saying "this input would be correct to me if I threw away these letters in the keyword". That's just retarded.
What they should and should not do can be easily found out by looking at your contract. And that's the end of the story. If you want free market, act like a responsible market participant.
Then it's not just a modem. Do you have a separate router or just your "modem"?
If you have a router, then you're doing an unnecessary double-router setup. If you don't, then the whole point is moot. A modem is transparent to layer 3 and provides a common layer 2 among different layer 1s.
The (separate) router on the LAN side of the modem needs to be aware of the 192.168.100/24 on its WAN side or else it won't know how to reach it on layer 3, regardless of every traffic passing thourgh the modem on layer 2.
No, the default gateway is your ISP. Otherwise, your modem would be a router.
If you use 10/8 internally, then your router will either forward packets for 192.168.100.1 to your ISP or drop them entirely. What makes you think just putting a device with 192.168.100.1 on the WAN side of your router makes it reachable if your router doesn't know anything about 192.168.100/24 on that interface?
Seriously, get a clue about networking and routing.
If the modem is using an RFC1918 address and is sitting on the WAN side of the router and the router is blocking RFC1918 on its WAN interface, what do you think will happen?
Maybe you should think more or stop posting about topics you don't understand.
FUD.
Free certs technically are exactly the same as every other cert. What you probably mean is to choose a higher validation than DV. That's the only reason you should pay someone money. But that has nothing to do with which devices accept your cert. That is a matter of server config and how you configure your TLS algorithms.
The point is, when that thing is still running, what prevents the Internet service you're using from switchting it into recording state remotely? Just because it doesn't transmit data "right now", doesn't mean it can't be made to, remotely.
However, that's exactly the reason why I wouldn't use anything "cloud" in the first place. Give me a cam that can upload to my server. I don't care if it's really off or not, if I can firewall it to only talk to my services.
As such, this "problem" is only a problem because it highlights the bad decision someone made in the first place, namely using "cloud-based" bullshit.
Cryptographers are our best hope.
What is this headline supposed to suggest? Trust cloud providers? LOL.
Which is apparently nothing. Thanks for clarifying.
Fear not. Microsoft itself is giving you hashes for all their images:
https://msdn.microsoft.com/en-...
You can safely pirate and verify.
Simple, the username is to be considered public knowledge. It's visible when entering it everywhere, it may be in ~/.ssh/config, it's not a secret.
Just assume the whole world knows it already. All strength must come from the password either way, so don't even start to treat the username as some sort of secret.
"Oh, OP! Don't remove your CRL checks by means of a self-inflicted MitM attack because then you're not secure against real MitM attacks!"
It's hilarious how you fail to see the connection.
Are you referring to the zsh option which also wouldn't protect you from rm -fr /, funny man?
Not so fast, Sherlock.
xargs doesn't handle shell functions, only external binaries.
Whether there's someone sitting on your line and grabbing your traffic or tampering with it is completely irrelevant because that problem exists in any case. By running your own resolver, you don't publish your queries directly to a third party on top of that and that's a good thing.
That's what you get when offering VPN access must include proper client configs because users are clueless and want to be "secure" by hitting a button.
I guarantee you that I could take the credentials of each and every one of these VPN offers, put them into my router and tunnel all my clients properly(!) without any leaks.
It's not the VPN that is flawed, it's the CLIENT SETUP. For people with a clue, that's a distinction.
If you alias rm to rm -i, what do you think rm -fr gets expanded to?
Could it be rm -i -fr in which case the -f overrides the -i anyway? Oh great sysadmin, can you clarify?
You mean in an amateurish way that can overload shell buffers?
Try
while read i; do ...; done < ips.txt
or
xargs ... < ips.txt
What are you even doing on the Internet without an ad blocker? Don't complain about things which are in your own responsibility, fool.
This is about queued TRIM vs. just TRIM, not TRIM vs. no TRIM at all.
When it comes to IT, I'll gladly let the hipsters deal with the pain and the data loss for a 0.5% speedup and use whatever they came up with - and is still relevant - after 10 years. Thank you very much.
From http://www.openbsd.org/errata5... (emphasis mine)
009: SECURITY FIX: June 11, 2015 All architectures
Fix several defects from OpenSSL:
CVE-2015-1788 - Malformed ECParameters causes infinite loop
CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time
CVE-2015-1792 - CMS verify infinite loop with unknown hash function
Note that CMS was already disabled in LibreSSL. Several other issues did not apply or were already fixed and one is under review.
For more information, see the OpenSSL advisory.
A source code patch exists which remedies this problem.
Though I'm really curious how "has security benefits" has nothing to do with security. That's a strange one.