Re: Files corrupted by one byte when downloading from my HTTPD server, any idea?
On Wed, Jun 07, 2017 at 06:10:43AM -0400, tec...@protonmail.com wrote: > Hello, > > I am using 6.1 Release - all patched, including packages with mtier. > > I'm running a PHP56 web server, I am initiating automatic downloads using > headers but whenever I download an image it cant be opened because no matter > what image type it is I get: > > Error interpreting JPEG image file (Not a JPEG file: starts with 0x0a 0xff) > > I have been trying to figure this out all morning, I found a blog post which > a guy has the exact same problem. > https://shareithq.wordpress.com/tag/php-nginx-or-php-seems-to-be-adding-1-byte-to-image-files/ > > But I tested his fix on the file, and it works.. > > tail -c +2 avatest_local.jpg > avatest_fixed.jpg > > Is it possible some sort of automatic compression is in use on the system? or > is that just ridiculous? > > Has anyone experienced this before and worked out the issue? Thanks It also might be remnants of chunked transfer encoding. This can happen if there is a 'smart' backend that encodes data into chunks (for some reason) and then reverse proxy encodes this into chunks again. -- Ivan Markin
Re: Booting encrypted drive from another device
Ted Unangst: > If an adversary gains possession of your hard drive and gives it back to you, > throw it away. li...@wrant.com: > The advice Ted gives is much more than simply correct, it can further > be extended to "do NOT accept electronics from people you don't know": Now think about the electronic devices that you bought from people you don't know, produced by people you don't know using design that is known only by people you don't know [maybe s/know/trust/g]. At the moment we have only small bits of verifiable hardware/OSHW so it's impossible to have "one solution" that covers all the threat models, unfortunately. One should consider their threat models exaggerating their "depth" to allow the moving towards free hardware. Moving your bootloader away from semi-trusted encrypted drive is going to defend you against EvilMaid and friends by *some adversaries* and within *some threat models*. -- Ivan Markin
Re: Booting encrypted drive from another device
Bodie: > What is that security reason worth of not using default full disk > encryption? Have a look at e.g. Evil Maid Attack [1]. One may want to bear a trusted bootloader with themselves and leave raw full-encrypted drive in some 'hostile' environment. [1] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html -- Ivan Markin
Re: Corrections to the Release Song Lyrics page
li...@wrant.com: > You're not part of the OpenBSD developers, you're coming from a free > mail provider (gmail). You show nothing to validate your suggestion. > You should probably stop making corrections in people's names unless > you get appointed to do so by the project. Until then, this is just > ignored, and wastes bytes, electricity, time, mostly yours. Re-read: > > ..you are introducing errors that cannot be confirmed.. We all have > better things to do. from [http://marc.info/?m=144605715428106] What the heck is wrong with you? Why can't you stop offending people and discourage them to contribute? If someone want to improve then there's nothing wrong with it. Everybody have different set of skills and they're trying to do a good thing as they _can_. "Waste of developers' time", "good quality standards"? If you have something to add/clarify about this suggestion from Tae Wong then go ahead and do it instead of "lowering mailing list quality standards" by yourself. > You're not part of the OpenBSD developers, you're coming from a free > mail provider (gmail). Do you think that it's OK to discriminate people? Have you noticed that you did so? P.S. I'm not going to feed you.
Re: hidden services stopped working
Theo de Raadt: > I am really impressed by the analytical skills I observe here. > > I observe: "the system is complex, I can't figure it out, I'll blame > everything, and use more stuff I don't understand". The problem is definely with ntpd because ntpd reports about invalid-then-valid peers to syslog right before Tor's complaints about timewrap. I don't see anything wrong about proposing a dirty fix that can solve the problem for a while. > Maybe the fortress fell over because you didn't have enough Lego. Maybe. -- Ivan Markin
Re: hidden services stopped working
a...@riseup.net: > Thanks for the reply and the help Ivan but I'm actually already doing exactly > what you suggested. Checking the time is one of the first things I thought of > but this is not that unfortunately. I don't have this problem on 5.9 myself > and even snapshots were fine up until the update. Your problem is > interesting though. > Let me know if you come accross anything new on that, again thanks for you > time on this. What do you mean by "checking the time"? It just jumps forward for about 150s and immediately restores. So it's not so visible. Though it makes Tor to break all built circuits. Have a look at your Tor log with `notice` debug level. There are probably reports like this: "Your system clock just jumped 150 seconds forward; assuming established circuits no longer work." -- Ivan Markin
Re: hidden services stopped working
Theo de Raadt: >> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate` >> [3] to fetch time over TLS. It works fine for me for several days by now. > > That is the worst possible advice ever. > > You are far better off letting your machines free-run. Why it's so wrong? ares, using tlsdate to sync time is not required. -- Ivan Markin
Re: hidden services stopped working
Hi ares,
a...@riseup.net:
> After a snapshot update on the 26th for amd64 I have lost the ability to
> connect to hidden services. I have pf rules to transparently proxy all
> connections taken from the wiki @ https://trac.torproject.org/projects/
> tor/wiki/doc/TransparentProxy#BSDPF. With the exception of using
> divert-to rules istead of the rdr-to rules everything else is exactly
> the same. It all worked fine up to the recent update. After a few days
> and a few snapshot versions I can't seem to troubleshoot what's changed
> or where it's failing. No errors or blocks in syslog or pflog repectively.
> Clearnet works fine and is all routed through tor and using tor-resolve
> on hidden services resolves the address just fine but trying to connect
> through irc or web browser to hidden services fails after timeout. Any
> help would be greatly appreciated. Attached a ktrace of lynx trying to
> connect to the duckduckgo hidden service. Thanks in advance guys!
> P.S. Triple checked pf rules and entire tor config, system time, and
> virtual address allocation
I've encountered recently that system time jumps repeatedly thus
breaking all curcuits and even more time-sensitive Onion Services as
well. This is a problem that I'm now investigating.
As you said, you're using snapshot version. But this problem also
present in 5.9 release branch and started around the same time. Then it
should not have roots in the recent code.
At the moment the problem narrows down to `ntpd.conf` in the default
install. According to this [1] commit, `ntpd` is enabled by default and
uses contraints over TLS from `www.google.com` (do we trust Google
now??). Same NTP peers work fine on another non-OpenBSD machines so my
best guess at the moment that time taken from `www.google.com` is wrong
(or the fetching method). Maybe Google changed their time logic.
Another hint is that these OpenBSD machines do DNS over Tor ('DNSPort'
option) and thus get different Google IP each time (Google tries to
resolve IP addresses that are nearby). Then ntpd takes average of these
clocks (different IPs) according to the manpage.
As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
[3] to fetch time over TLS. It works fine for me for several days by now.
[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/ntpd.conf.diff?r1=1.12=1.13
[2] /etc/rc.d/ntpd stop
rcctl disable ntpd
[3] https://github.com/ioerror/tlsdate
--
Ivan Markin
Re: CRYPTO volume created, but appears as full
Stefan Sperling: > On Sat, May 28, 2016 at 06:03:48PM +0000, Ivan Markin wrote: >> Sebastien Marie: >>> Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the >>> /dev/sd* aren't created by default. >> >> Why it is so? Can this be found somewhere in documentation? > > If the ramdisk shipped with all possible device nodes, the small > ramdisk filesystem would run out of inodes. > > The installer script compensates for this by creating device nodes it > knows will be needed, so normally you don't have to think about this. > Because the install script does not support FDE installs at present, > the /dev/rsd3c device node is not created automatically. > Thanks for the explanation! It would be great if someone can add this note to the FAQ [1]. [1] https://www.openbsd.org/faq/faq14.html#softraidFDE -- Ivan Markin
Re: CRYPTO volume created, but appears as full
Sebastien Marie: > Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the > /dev/sd* aren't created by default. Why it is so? Can this be found somewhere in documentation? -- Ivan Markin
Re: CRYPTO volume created, but appears as full
Robert Campbell: > I followed the steps in the FAQ for setting up full disk encryption. > Everything goes according to plan until I attempt to write zeros to the > first megabyte of the new pseudo-device; as you can see below, dd informs > me that the file system is full, that there is no space left on the device. > Interestingly, the last line of dmesg is also "uid 0 on /: file system > full". I've retried this with 5.9 and -current, but the outcome is the > same. I've also tried rebooting after disklabel and bioctl. I have pasted > below the relevant sequence, followed by the full dmesg. I've experienced same behavior. It always happened when sd(4) driver is in use and never with wd(4). I managed to enable FDE using random disklabel(8) tricks. This is probably a bug in sd(4). Try to initialize your disk with standard disklabel without CRYPTO first (e.g. via installation program then exit to shell). Then perform the steps from FDE guide. -- Ivan Markin
Re: Impossibility of cryptographic verification of downloads
Eduard - Gabriel Munteanu: > Well, you could certainly put the key and signify sources on the > main website. As Theo said they're at the corresponding pages [s/http/https/g]: > You mean like here? > > http://www.openbsd.org/59.html > > and > > http://www.openbsd.org/58.html > > and > > http://www.openbsd.org/57.html > > and > > http://www.openbsd.org/56.html signify is pretty straightforward (and awesome!) tool so it's not that hard to imlement it yourself. But you don't have to. There are many portable reimplementations. > The CVS thing doesn't seem to be HTTPS-enabled. This note seems to be truly reasonable to me. If OpenBSD already got Let's Encrypt this month and deployed it for www.openbsd.org it should not be hard to expand it to *.openbsd.org. Yeah, X.509 is a piece of shit but having this option is better than nothing. #safedefaults -- Happy verifying, Ivan Markin
