Re: [patch] cwm: Preserve stacking order during cycling
On Wed, Nov 25, 2015 at 05:44:28PM +0100, Vadim Vygonets wrote: > Quoth Артур Истомин on Tue, Nov 24, 2015: > > Yes, exactly. Example: https://imgur.com/rUPxpTF There is mplayer behind > > firefox. In the beginning everything is working properly. Alt+Tab work for > > all three windows. Some time later mplayer does not appear anymore through > > Alt+Tab and i need to press Alt+Down, Alt+Down. > > Does it only happen to windows that are fully obscured? Do you > have to get the mouse pointer into the window before you can > cycle to it again? > > If you're willing, we can do the following: you update to current > plus my patches (I won't roll back), I prepare a patch with debug > prints, you run it until you encounter the bug and send me the > output, and we try to understand what's going on. Interested? Vadik, sorry for silent. I upgraded cwm to latest from current two days ago (need to comment out pledge's stuff) and my bug disappeared :)
Re: OpenBSD errata, Dec 3, 2015
On Sun, Dec 06, 2015 at 06:04:18AM -0500, Ted Unangst wrote: > Bob Beck wrote: > > Fixes have been commited for both CVE-2015-1394 and CVE-2015-1395. > > CVE-2015-1394 warrants an errata. > > > The errata for CVE-2015-1394 is available for OpenBSD 5.8 and OpenBSD > > 5.7 from the master site as well as the mirrors: > > To clear up any confusion, the CVE numbers should be 3194 and 3195. and ftp, isakmpd and iked need to be rebuilded for 5.7 and 5.8
Re: [patch v2] cwm: Preserve stacking order during cycling
On Sun, Nov 22, 2015 at 04:57:45PM +0100, Vadim Vygonets wrote: > I accidentally killed restacking on group_show(). Sorry about > that. Here's version 2 of the patch. > > Vadik. > > Quoth Vadim Vygonets on Sat, Nov 21, 2015: > > After cycling through many windows, the original window may be > > obscured by many others, and if you still want to see its > > contents you end up doing the Alt-Tab-Tab-Tab-Tab-Tab, Alt-Tab, > > Alt-Tab dance. > > > > This patch adds restacking of windows during cycling. Hold Alt, > > press Tab and a window will be raised. Press Tab again while > > still holding Alt and that window will be lowered back before > > another is raised. Once you release Alt, the original window > > will be hidden behind no more than one other (the target), > > assuming it was raised before. I'am on 5.8-stable =( It's failed: Patching file group.c using Plan A... Hunk #1 failed at 34. Hunk #2 succeeded at 73 with fuzz 2 (offset -8 lines). 1 out of 2 hunks failed--saving rejects to group.c.rej done
Re: [patch] cwm: Preserve stacking order during cycling
On Sun, Nov 22, 2015 at 05:56:09PM +0100, Vadim Vygonets wrote: > День добрый, > > Quoth Артур Истомин on Sun, Nov 22, 2015: > > It is always reproducable for me when 3 or more windows opened. This > > is not immediately, but eventualy I can't access to the window located > > below one or two other through Alt+Tab. > > Sorry to be so explicit, but just to make sure I understand you > correctly: while holding Alt, you press Tab several times, and > you get to the original window (the one you started with) without > seeing one or more non-hidden windows in the process? Yes, exactly. Example: https://imgur.com/rUPxpTF There is mplayer behind firefox. In the beginning everything is working properly. Alt+Tab work for all three windows. Some time later mplayer does not appear anymore through Alt+Tab and i need to press Alt+Down, Alt+Down. > > > It is very annoying, that Alt+Tab in cwm does not work in "classic" > > way, cycling ALL windows in order. > > It should (unless you remapped M-Tab or have "ignore" directives > in your .cwmrc). What you describe sounds like cwm losing > windows, or marking them as hidden or ignored for some reason. > > Do you notice any common conditions in which it happens? E.g., > after hiding/showing groups, or after not doing it for a while? > Do particular clients (programs) drop off the list more often, or > does it happen when particular clients are shown? What's your > favourite client (i.e., what terminal emulator do you use)? Do > you have any surprises in your .cwmrc? I don't see any common conditions. In my ~/.cwmrc only one line: fontname "-xos4-terminus-medium-r-*-*-16-*-*-*-*-*-iso10646-1"
Re: [patch] cwm: Preserve stacking order during cycling
On Sun, Nov 22, 2015 at 12:58:42AM +0100, Vadim Vygonets wrote: > Quoth Артур Истомин on Sun, Nov 22, 2015: > > On Sat, Nov 21, 2015 at 02:10:15AM +0100, Vadim Vygonets wrote: > > > After cycling through many windows, the original window may be > > > obscured by many others, and if you still want to see its > > > contents you end up doing the Alt-Tab-Tab-Tab-Tab-Tab, Alt-Tab, > > > Alt-Tab dance. > > > > Even this not always helps. Often I need press Alt+Down or Alt+Up > > to get window up. > > Oh, I haven't seen it happening (but then I'm a new user). > Sounds weird. If you have a way to reproduce it, I'd like to > know (although I'm reluctant to promise to work on it). It is always reproducable for me when 3 or more windows opened. This is not immediately, but eventualy I can't access to the window located below one or two other through Alt+Tab. In such case Alt+Down rush to rescue :) It is very annoying, that Alt+Tab in cwm does not work in "classic" way, cycling ALL windows in order. But I've never seen someone complain and thought it was my local problem. You became the first ray of hope :) I'll try your patch in 10-12 hours after some sleep.
Re: [patch] cwm: Preserve stacking order during cycling
On Sat, Nov 21, 2015 at 02:10:15AM +0100, Vadim Vygonets wrote:
> Hi,
>
> After cycling through many windows, the original window may be
> obscured by many others, and if you still want to see its
> contents you end up doing the Alt-Tab-Tab-Tab-Tab-Tab, Alt-Tab,
> Alt-Tab dance.
Even this not always helps. Often I need press Alt+Down or Alt+Up
to get window up.
Thanks for your effort.
>
> This patch adds restacking of windows during cycling. Hold Alt,
> press Tab and a window will be raised. Press Tab again while
> still holding Alt and that window will be lowered back before
> another is raised. Once you release Alt, the original window
> will be hidden behind no more than one other (the target),
> assuming it was raised before.
>
> What do you think?
>
> Vadik.
>
> --
> Nondeterminism means never having to say you are wrong.
> ? cwm-incresize.diff
> ? p
> Index: calmwm.h
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.311
> diff -u -r1.311 calmwm.h
> --- calmwm.h 12 Nov 2015 21:28:03 - 1.311
> +++ calmwm.h 21 Nov 2015 00:12:09 -
> @@ -62,6 +62,8 @@
> #define CWM_CLIENT_RCYCLE0x0002
> #define CWM_CLIENT_CYCLE_INGRP 0x0004
>
> +#define CWM_CLIENT_RESTACK_GRP 0x0001
> +
> #define CWM_CLIENT_TILE_HORIZ0x0001
> #define CWM_CLIENT_TILE_VERT 0x0002
>
> @@ -385,6 +387,7 @@
> void client_applysizehints(struct client_ctx *);
> void client_config(struct client_ctx *);
> struct client_ctx*client_current(void);
> +void client_restack(struct client_ctx_q *, int);
> void client_cycle(struct screen_ctx *, int);
> void client_cycle_leave(struct screen_ctx *);
> void client_delete(struct client_ctx *);
> Index: client.c
> ===
> RCS file: /cvs/xenocara/app/cwm/client.c,v
> retrieving revision 1.214
> diff -u -r1.214 client.c
> --- client.c 12 Nov 2015 18:33:30 - 1.214
> +++ client.c 21 Nov 2015 00:12:09 -
> @@ -664,6 +664,50 @@
> }
>
> void
> +client_restack(struct client_ctx_q *clientq, int flags)
> +{
> +#define CLIENTQ_FOREACH(var, head, ingrp)\
> + for((var) = TAILQ_FIRST(head); \
> + (var) != TAILQ_END(head); \
> + (var) = (ingrp) ? \
> + TAILQ_NEXT(var, group_entry) : TAILQ_NEXT(var, entry))
> + struct client_ctx *cc;
> + Window *winlist;
> + int i, lastempty = -1;
> + int nwins = 0, highstack = 0;
> +
> + CLIENTQ_FOREACH(cc, clientq, flags & CWM_CLIENT_RESTACK_GRP) {
> + if (cc->flags & CLIENT_HIDDEN)
> + continue;
> + if (cc->stackingorder > highstack)
> + highstack = cc->stackingorder;
> + }
> + winlist = xreallocarray(NULL, (highstack + 1), sizeof(*winlist));
> +
> + /* Invert the stacking order for XRestackWindows(). */
> + CLIENTQ_FOREACH(cc, clientq, flags & CWM_CLIENT_RESTACK_GRP) {
> + if (cc->flags & CLIENT_HIDDEN)
> + continue;
> + winlist[highstack - cc->stackingorder] = cc->win;
> + nwins++;
> + }
> +
> + /* Un-sparseify */
> + for (i = 0; i <= highstack; i++) {
> + if (!winlist[i] && lastempty == -1)
> + lastempty = i;
> + else if (winlist[i] && lastempty != -1) {
> + winlist[lastempty] = winlist[i];
> + if (++lastempty == i)
> + lastempty = -1;
> + }
> + }
> +
> + XRestackWindows(X_Dpy, winlist, nwins);
> + free(winlist);
> +}
> +
> +void
> client_cycle(struct screen_ctx *sc, int flags)
> {
> struct client_ctx *newcc, *oldcc;
> @@ -704,9 +748,15 @@
> }
> }
>
> - /* reset when cycling mod is released. XXX I hate this hack */
> - sc->cycling = 1;
> client_ptrsave(oldcc);
> + if (!sc->cycling) {
> + /* reset when cycling mod is released. XXX I hate this hack */
> + sc->cycling = 1;
> + screen_updatestackingorder(sc);
> + } else {
> + client_restack(&sc->clientq, (flags & CWM_CLIENT_CYCLE_INGRP) ?
> + CWM_CLIENT_RESTACK_GRP : 0);
> + }
> client_ptrwarp(newcc);
> }
>
> Index: group.c
> ===
> RCS file: /cvs/xenocara/app/cwm/group.c,v
> retrieving revision 1.121
> diff -u -r1.121 group.c
> --- group.c 10 Nov 2015 20:05:33 - 1.121
> +++ group.c 21 Nov 2015 00:12:09 -
> @@ -34,7 +34,6 @@
>
> static struct group_ctx *group_n
Re: Oct 15 OpenBSD errata and LibreSSL releases
On Thu, Oct 15, 2015 at 08:29:25PM -0400, Ted Unangst wrote: > The OBJ_obj2txt function in libcrypto contains a one byte buffer overrun > and memory leak, as reported by Qualys Security. This can be abused by an > attacker to cause a denial of service in some cases. > > Patches are now available for OpenBSD as well as new releases of LibreSSL > portable. 5.6, 5.7, and 5.8 are affected, as well as all releases of LibreSSL. > > Note that in addition to the instructions to rebuild libcrypto in the patch, > some binaries may link statically with libcrypto (isakmpd, iked, ...) and need > rebuilding as well. And services restarted. Ted, what exactly binaries need to be rebuilded? isakmpd, iked, ftp(?) something else? > > OpenBSD patches: > http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/033_obj2txt.patch.sig > http://ftp.openbsd.org/pub/OpenBSD/patches/5.7/common/019_obj2txt.patch.sig > http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_obj2txt.patch.sig > > LibreSSL releases: > http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.0.6.tar.gz > http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.1.8.tar.gz > http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.2.4.tar.gz > > There will be a libressl-2.3.1 release coming, but as a reminder it's still a > development branch. (The OpenBSD patches should apply to 2.3.0 as well.) > > With the release of OpenBSD 5.8 in a few days, 5.6 will be officially retired > from support, and along with it LibreSSL 2.0. Hopefully, this will be the last > release in that line. > >
Re: Happy Birthday OpenBSD!
On Sun, Oct 04, 2015 at 05:30:33PM -0600, Bob Beck wrote: > > On Sun, Oct 04, 2015 at 05:27:51PM -0600, Bob Beck wrote: > > > > ** OpenBSD is turning 20, on January 18th 2015 ** > > Ok, and I'm an idiot.. OCTOBER 18th, 2015 I.E. coming up in two weeks > from today :) lol, thank you Bob, you make my day :))) > > > > > There will be an informal Birthday Party upstairs at the Hose and Hound pub > > in Calgary (http://www.thehose.ca/) > > > > At the very least, Theo de Raadt and I will be there starting from about 5 > > PM. > > > > Any and all are welcome to stop by and say hi, and to have a beer or > > thirteen. > > > > Cheers, > > > > -Bob > >
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Mon, Aug 10, 2015 at 12:23:44PM +0100, Stuart Henderson wrote: > On 2015/08/10 11:54, sam wrote: > > I am also of the opinion that if somebody/a method can discover bugs, > > they should report them. And if they can't, that method should be > > disclosed to allow others to continue their work. > > So you think others "should" do work for you, right? Whether that work is in > discovering and reporting bugs, or in preparing their code for release so you > can use it (maybe tidying, writing docs, fielding bug reports, > etc.etc.etc.)? This is how the capitalist system has always worked. Exploiting the weakness, folly or fanaticism. OpenBSD is the OS created mostly by a group of people with a strong belief that capitalism and/or democracy is right things for society. What is surprising?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
On Sun, Aug 09, 2015 at 03:38:25PM -0600, Theo de Raadt wrote: > > Awful lot of noise wherein people tell someone else what they should > > need to do with their time and their code. > > > > > > To the best of my knowledge, we've cited and/or thanked Maxime in the > > commits fixing the issues he's found, and we're glad to continue to > > receive his reports, whether or not they include patches. My > > apologies if we've failed to do so. > > Thanks for saying that Philip. > > I would like to point out the noise is coming from *users* -- not from > actual developers in the project. .so let's get rid of the users! I don't understand the purpose of your observations.
Re: softdep by default on AMD64
On Tue, Jul 28, 2015 at 06:19:11AM -0700, Chris Cappuccio wrote: > ?? ?? [art.is...@yandex.ru] wrote: > > On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: > > > "generally reliable" HAHAHAHAHA > > > > Why irony? It's more or less true for ALL modern computing system. > > Think of it as a selling point. OpenBSD ffs softdep: On the cutting > edge of reliability! Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) (ffs+softdep on softraid crypto)
Re: softdep by default on AMD64
On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: > "generally reliable" HAHAHAHAHA Why irony? It's more or less true for ALL modern computing system.
Re: Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors
On Fri, Dec 26, 2014 at 03:06:31AM +0600, Артур Истомин wrote: > https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf > > Abstract. > > Memory isolation is a key property of a reliable and secure computing > system-an access to one memory address should not have unintended side > effects on data stored in other addresses. However, as DRAM process > technology scales down to smaller dimensions, it becomes more difficult to > prevent DRAM cells from electrically interacting with each other. In this > paper, we expose the vulnerability of commodity DRAM chips to disturbance > errors. By reading from the same address in DRAM, we show that it is possible > to corrupt data in nearby addresses. More specifically, activating the same > row in DRAM corrupts data in nearby rows. We demonstrate this phenomenon on > Intel and AMD systems using a malicious program that generates many DRAM > accesses. We induce errors in most DRAM modules (110 out of 129) from three > major DRAM manufacturers. From this we conclude that many deployed systems > are likely to be at risk. We identify the root cause of disturbance errors as > the repeated toggling o! f ! > a DRAM row's wordline, which stresses inter-cell coupling effects that > accelerate charge leakage from nearby rows. We provide an extensive > characterization study of disturbance errors and their behavior using an > FPGA-based testing platform. Among our key findings, we show that (i) it > takes as few as 139K accesses to induce an error and (ii) up to one in every > 1.7K cells is susceptible to errors. After examining various potential ways > of addressing the problem, we propose a low-overhead solution to prevent the > errors. > > Example: > http://blog.sudhanshumishra.in/2014/12/memory-error-due-to-charge-leak.html > Tester (built on top of memtest): https://github.com/CMU-SAFARI/rowhammer > LKML discussion: https://lkml.org/lkml/2014/12/24/258 > > And now practical realisation: http://googleprojectzero.blogspot.ru/2015/03/exploiting-dram-rowhammer-bug-to-gain.html Excerpt: “Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.
Re: freetype vulns
On Sat, Mar 07, 2015 at 01:14:32AM -0700, Theo de Raadt wrote: > > On Thu, Mar 05, 2015 at 05:52:12PM +, Stuart Henderson wrote: > > > On 2015/03/05 12:41, Ted Unangst wrote: > > > > Boudewijn Dijkstra wrote: > > > > > Op Wed, 04 Mar 2015 23:12:07 +0100 schreef Ted Unangst > > > > > : > > > > > > Freetype (http://www.freetype.org/) 2.5.5 was released a little > > > > > > while ago, > > > > > > fixing some security vulnerabilities. Actually as I understand it, > > > > > > 2.5.4 > > > > > > fixed the vulns, then 2.5.5 fixed the fix. > > > > > > > > > > > > OpenBSD 5.7 will ship with 2.5.5; 5.6 shipped with 2.5.3 and is > > > > > > therefore > > > > > > vulnerable. > > > > > > > > > > > > [...] > > > > > > > > > > > > Unfortunately, the FreeType project does not appear to have made > > > > > > these patches > > > > > > available separately from the releases, which makes it difficult > > > > > > for us to > > > > > > apply backports to OpenBSD. > > > > > > > > > > I guess the most important thing is to give users the opportunity to > > > > > fix the vulns. Will there be a CVS tag that 5.6 users can use to > > > > > update FreeType to 2.5.5? > > > > > > > > No. That's too large a change. > > > > > > > > > > Specifically there was a major version number bump to the library in > > > the 2.5.4 update. That means that other programs built to use freetype > > > would also need to be re-built. > > > > > > Moving to -current is considerably easier. > > > > So, in fact all 5.6's users sitting with vuln freetype in base now. > > Excellent! > > Thank you for your wise commentary. > > Are you going to do something -- beyond just being sarcastic? Or is > this a demonstrating of your limited nature. > > The previous mails (enough of the bodies included above) are pretty clear > about the scope of the issue and the reasoning. > > Perhaps there is room here for someone to demonstrate that the wrong > decision has been made, by providing diffs, but the onus would be on > you. Have you started? No. I wouldn't lift a finger. It is your duty as a developer of "most secure OS". Do it! Or shut up and stop pretending that OpenBSD in any way secure to use.
Re: freetype vulns
On Thu, Mar 05, 2015 at 05:52:12PM +, Stuart Henderson wrote: > On 2015/03/05 12:41, Ted Unangst wrote: > > Boudewijn Dijkstra wrote: > > > Op Wed, 04 Mar 2015 23:12:07 +0100 schreef Ted Unangst > > > : > > > > Freetype (http://www.freetype.org/) 2.5.5 was released a little while > > > > ago, > > > > fixing some security vulnerabilities. Actually as I understand it, 2.5.4 > > > > fixed the vulns, then 2.5.5 fixed the fix. > > > > > > > > OpenBSD 5.7 will ship with 2.5.5; 5.6 shipped with 2.5.3 and is > > > > therefore > > > > vulnerable. > > > > > > > > [...] > > > > > > > > Unfortunately, the FreeType project does not appear to have made these > > > > patches > > > > available separately from the releases, which makes it difficult for us > > > > to > > > > apply backports to OpenBSD. > > > > > > I guess the most important thing is to give users the opportunity to fix > > > the vulns. Will there be a CVS tag that 5.6 users can use to update > > > FreeType to 2.5.5? > > > > No. That's too large a change. > > > > Specifically there was a major version number bump to the library in > the 2.5.4 update. That means that other programs built to use freetype > would also need to be re-built. > > Moving to -current is considerably easier. So, in fact all 5.6's users sitting with vuln freetype in base now. Excellent!
Re: LibreSSL: GOST ciphers implementation
On Wed, Nov 05, 2014 at 01:25:32PM -0700, Theo de Raadt wrote: > > On Wed, Nov 05, 2014 at 06:13:40PM +, Miod Vallat wrote: > > > > This is suspicious person for me (group of people?). There are lots of > > > > commits since about 2011 in many low-level and/or critical components > > > > from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, > > > > openssl etc, etc.. > > > > > > > > I'm almost certainly wrong, but not too much there competencies for one > > > > person? > > > > > > This kind of comment is an insult, both to the submitter, and to our > > > code review process. > > > > On the issue of the code review: > > http://cm.bell-labs.com/who/ken/trust.html (Ken Thompson, 1984) > > And... do you trust me? > Do you trust Miod? > > Why? > > No really, precisely why do you trust us? > > What a joke. > > > > > That said, I remember Itojun used to have his name tied to way too many > > > projects, not only because he was an amazing programmer, but also > > > because he acted as the english spokeperson for many other japanese > > > developers whose english skills weren't as good as Itojun's. This might > > > be a similar story here, with russian people not good enough at english. > > > > I said that 99.9% I'm wrong. But if I'm right, you guys will have a > > problem far worse than ever with ipsec. I believe that the code review > > of such diffs should be tightened when it comes to such important things > > as the kernel and/or the crypto. Tightened up to accepting of code only > > from people personally known to core developers. > > That is quite a fiction. > > How do we find people on the internet who care, and knit them into a > community, and then somewhere down the road meet them and have them > become this so-called 'core developer' group? > > We start reading code from them. > > Perhaps it is easier for people who are not part of this process, to > find ways to disparage this human effort. > > > Otherwise OpenBSD's security little different from Linux security in > > today's reality. Eric S. Raymond's bazaar - The Achilles heel in a > > situation, where you can not say with certainty who came from diff. > > Well, we never promised our processes to be better than the standard > human processes. > > But I guess you believe we can do better, without any significant > backing. > > So who's the fool now? > > I think you are. So, in fact, all that you said: we address and solve technical problems only. But this is the real world, not all problems can be solved in it by code. It was not accusation to Dmitry, like you said in another e-mail. I'm just trying to point out the problem, which seems to me important. I perfectly see the folly of my proposal. But it was a proposal, attempt to begin discussion of the problem. But based on your answer, you do not see the problem. You can not see the forest for the trees. You think, that all security problems are technical problems, that can be solved with the help of the compiler. But with such mindset, at current trends, in 5-7 years the only code that you can trust in the project, it will only your own code.
Re: LibreSSL: GOST ciphers implementation
On Wed, Nov 05, 2014 at 06:13:40PM +, Miod Vallat wrote: > > This is suspicious person for me (group of people?). There are lots of > > commits since about 2011 in many low-level and/or critical components > > from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, > > openssl etc, etc.. > > > > I'm almost certainly wrong, but not too much there competencies for one > > person? > > This kind of comment is an insult, both to the submitter, and to our > code review process. On the issue of the code review: http://cm.bell-labs.com/who/ken/trust.html (Ken Thompson, 1984) > That said, I remember Itojun used to have his name tied to way too many > projects, not only because he was an amazing programmer, but also > because he acted as the english spokeperson for many other japanese > developers whose english skills weren't as good as Itojun's. This might > be a similar story here, with russian people not good enough at english. I said that 99.9% I'm wrong. But if I'm right, you guys will have a problem far worse than ever with ipsec. I believe that the code review of such diffs should be tightened when it comes to such important things as the kernel and/or the crypto. Tightened up to accepting of code only from people personally known to core developers. Otherwise OpenBSD's security little different from Linux security in today's reality. Eric S. Raymond's bazaar - The Achilles heel in a situation, where you can not say with certainty who came from diff.
Re: LibreSSL: GOST ciphers implementation
On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote: > > Two weeks has passed. Is there anything that I can do to > > push GOST ciphers towards LibreSSL? > > Sorry about that. Joel and/or I need to review the diff again and push > it. I'll try to find time for this next week-end (famous last words). > > Miod This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person?
Re: LibreSSL: GOST ciphers implementation
On Mon, Oct 20, 2014 at 01:57:44PM +0400, Dmitry Eremin-Solenikov wrote: > Hello, > > It took a while longer than I expected, but I think that > the GOST ciphers implementation is complete now > at https://github.com/libressl-portable/openbsd/pull/6 > > I still expect issues when Windows GOST CSP vendors > will work on TLS 1.2 implementation (up to now they > only provide TLS 1.0). However that will have to be fixed > in future (when there will be at least one GOST + TLS 1.2 > implementation). > > Could you please provide review, comments/ How do you manage so many? Alsa (and linux kernel overall), debian packages maintain, wikipedia editing, cryptography (gnupg and now GHOST for libressl) etc, etc, etc.. Are you God? )
Re: misprint in cvs(1) man page
On Sat, Jul 19, 2014 at 06:57:47PM +0200, olli hauer wrote: > On 2014-07-19 17:51, Jason McIntyre wrote: > > On Sat, Jul 19, 2014 at 09:00:16AM +, ?? ?? wrote: > >> On Sat, Jul 19, 2014 at 07:55:12AM +0100, Jason McIntyre wrote: > >>> On Sat, Jul 19, 2014 at 06:41:35AM +, ?? ?? wrote: > On Sat, Jul 19, 2014 at 07:01:57AM +0059, Jason McIntyre wrote: > > On Sat, Jul 19, 2014 at 05:26:41AM +, ?? ?? > > wrote: > >> There is misprint in cvs(1) man page for import command: > >> > >> 'You can use this command both for initial creation of a repository, > >> and > >> for wholesale updates to the module _form_ the outside source' > >> > >> must be: > >> > >> 'You can use this command both for initial creation of a repository, > >> and > >> for wholesale updates to the module _from_ the outside source' > >> > > > > cvs is 3rd party. if you find bugs in their docs i suggest you check out > > whether they still exist in the lastest revision and submit your reports > > to them directly. > > From http://www.openbsd.org/opencvs/ "OpenCVS is developed by the > OpenBSD Project". Version CVS in OpenBSD is not OpenCVS? > > >>> > >>> yes, that is openbsd cvs. but it is not currently installed. the page > >>> you're reading is 3rd party cvs(1). > >> > >> There is no such misprint in latest stable release cvs > >> http://download.savannah.gnu.org/releases/cvs/source/stable/1.11.23/cvs-1.11.23.tar.bz2 > >> > > > > so sounds like it's been fixed upstream, and we should get it when we > > pull in newer sources. > > > > The (last) upstream sources are already from 08-May-2008 ... Recursion. In base we have cvs 1.11.1p1 (2001). Latest version 1.11.23 (2008). Version in base, apparently, will not update. As errors in documentation are treated as bugs we have eternal bug.
Re: misprint in cvs(1) man page
On Sat, Jul 19, 2014 at 07:55:12AM +0100, Jason McIntyre wrote: > On Sat, Jul 19, 2014 at 06:41:35AM +, ?? ?? wrote: > > On Sat, Jul 19, 2014 at 07:01:57AM +0059, Jason McIntyre wrote: > > > On Sat, Jul 19, 2014 at 05:26:41AM +, ?? ?? wrote: > > > > There is misprint in cvs(1) man page for import command: > > > > > > > > 'You can use this command both for initial creation of a repository, and > > > > for wholesale updates to the module _form_ the outside source' > > > > > > > > must be: > > > > > > > > 'You can use this command both for initial creation of a repository, and > > > > for wholesale updates to the module _from_ the outside source' > > > > > > > > > > cvs is 3rd party. if you find bugs in their docs i suggest you check out > > > whether they still exist in the lastest revision and submit your reports > > > to them directly. > > > > From http://www.openbsd.org/opencvs/ "OpenCVS is developed by the > > OpenBSD Project". Version CVS in OpenBSD is not OpenCVS? > > > > yes, that is openbsd cvs. but it is not currently installed. the page > you're reading is 3rd party cvs(1). There is no such misprint in latest stable release cvs http://download.savannah.gnu.org/releases/cvs/source/stable/1.11.23/cvs-1.11.23.tar.bz2
Re: misprint in cvs(1) man page
On Sat, Jul 19, 2014 at 07:01:57AM +0059, Jason McIntyre wrote: > On Sat, Jul 19, 2014 at 05:26:41AM +, ?? ?? wrote: > > There is misprint in cvs(1) man page for import command: > > > > 'You can use this command both for initial creation of a repository, and > > for wholesale updates to the module _form_ the outside source' > > > > must be: > > > > 'You can use this command both for initial creation of a repository, and > > for wholesale updates to the module _from_ the outside source' > > > > cvs is 3rd party. if you find bugs in their docs i suggest you check out > whether they still exist in the lastest revision and submit your reports > to them directly. >From http://www.openbsd.org/opencvs/ "OpenCVS is developed by the OpenBSD Project". Version CVS in OpenBSD is not OpenCVS?
misprint in cvs(1) man page
There is misprint in cvs(1) man page for import command: 'You can use this command both for initial creation of a repository, and for wholesale updates to the module _form_ the outside source' must be: 'You can use this command both for initial creation of a repository, and for wholesale updates to the module _from_ the outside source'
Re: GOST was removed
On Wed, Apr 16, 2014 at 08:15:02AM +, Артур Истомин wrote: > I assumed that, for establishment GOST, it is enough to recompile > OpenSSL in source tree and install it. Situation worsens in that it is > the only implementation of GOST, so that there are no alternatives for > unix and unix-like systems. I am liar. Libgrypt, noteworthy changes between version 1.5.0 and 1.6.0 (Dec 16 18:49:01 CET 2013): * Added limited support for the GOST 28147-89 cipher algorithm. * Added support for the GOST R 34.11-94 and R 34.11-2012 (Stribog) hash algorithms.
Re: GOST was removed
On Tue, Apr 15, 2014 at 03:34:36PM -0600, Theo de Raadt wrote: > >Log message: > >Remove the GOST engine: It is not compiled or used and depends on the > >"dynamic engine" feature that is not enabled in our build. People who > >need it can still pull it out of the Attic; if it is to have a Russian > >engine just because it's a Russian engine. > >-- > > > >This hash function is a formal requirement in all public institutions in > >Russia. Removing it, the work of people using OpenBSD in these > >institutions is greatly complicated by its return. > > First off, this library primary function is to supply two major > components for use by people: > > SSL protocol > raw symmetric & assymetric crypto functions > > Meeting the "requirements of public institutions" is pretty low on the > list right about now. Quite frankly, I do not want my own government > using OpenSSL for anything. As it is now, it is not suitable. > > >This is a political decision, or indeed it is necessary for the cleaning > >OpenSSL? Do not throw out the child along with the bath. > > Dynamic loading of crypto libraries into a framework is not > acceptable. Furthermore, if you dig just a bit deeper, you will > quickly realize that this code has not worked in our tree before. It > was not enabled. It did not work. > > In the interests of full disclosure, do you work for the government or > sell to the government? I'm not sure what it means "to work for the government" in terms of the English language. I am now in the process of transfer to the IT-department of city hall of small town in the geographical center of Russia. In the area of my responsibility will be the network infrastructure of city hall. This is "work for the government"? I assumed that, for establishment GOST, it is enough to recompile OpenSSL in source tree and install it. Situation worsens in that it is the only implementation of GOST, so that there are no alternatives for unix and unix-like systems. Yet your words as the words of Bob and Reyk, given your competence in this area, sound convincing. If it makes the system more secure, it is a sensible move. I am glad that there is no politics.
GOST was removed
Log message: Remove the GOST engine: It is not compiled or used and depends on the "dynamic engine" feature that is not enabled in our build. People who need it can still pull it out of the Attic; if it is to have a Russian engine just because it's a Russian engine. -- This hash function is a formal requirement in all public institutions in Russia. Removing it, the work of people using OpenBSD in these institutions is greatly complicated by its return. This is a political decision, or indeed it is necessary for the cleaning OpenSSL? Do not throw out the child along with the bath.
