Perhaps for now we could have a new attribute `force_export_body = true` that overrides the content type restriction, and then document the caveat that using it to get access to binary data or large data may not work correctly or may hurt Terraform performance.

Although the binary safety is part of this, not loading large bodies into memory is another. We didn't yet flesh out all the functionality for this, but I expected that much like the `aws_s3_bucket_object` data source it would grow to also export useful header information that can be used to determine, for example, if the data has changed without actually downloading the data, in order to decide if a re-deployment is required. (This is commonly done with S3 objects representing Lambda function source archives, for example.)


```
    <div>
        <h1>鹿柴</h1>
        <div>
            <span class="label label-default"><i class="fa fa-tag" aria-hidden="true"></i> 诗词歌赋</span>
        </div>
        <div class="text-small text-gray mt-1">
            <span>王维</span>
            <time class="ml-2">2017年1月1日 10:00</time>
            <a  class="ml-2" href="#">编辑</a>
        </div>
        <div class="markdown-body">
            <p>
                空山不见人，但闻人语响。<br/>
                返影入深林，复照青苔上。
            </p>
        </div>
    </div>
```

css
```
.text-small{
	font-size: 12px !important;
}

.text-gray {
	color: #586069 !important;
}

.mt-1 {
	margin-top: 4px !important;
}

.ml-2 {
    margin-left: 8px !important;
}

.markdown-body{
	padding-top: 10px;
	padding-bottom: 10px;
}
```
供参考


PCM-NRGSim-NREL-SBV (Myoldmopar) - x86_64-Linux-Ubuntu-14.04-cppcheck-1.61: OK (0 of 0 tests passed, 0 test warnings)

![Build Badge](http://img.shields.io/badge/build%20status-passing-green.png)


You guys are on fire today, congrats :)


不要使用多个 `panel-body`, 使用 `list-group` ，参考 http://getbootstrap.com/components/#panels-list-group


Since you're fine with sharing private correspondence in public, let's expose some snakes to the sunlight:

[01:56:17] <RageLtMan> Skimming the diff of pax-only patch in strcat's repo branch makes me think porting this is somewhat nightmarish since we're going to need to evaluate all that asm. Probably need to think about automated testing infrastructure both in terms of builders and fuzzers + reporters
[01:57:09] <strcat> a lot isn't going to be wanted
[01:57:18] <RageLtMan> I am actually in the process of building something quite similar, also having to deal with kernel code at work...
[01:57:22] <strcat> the main thing are RAP asm changes
[01:58:01] <RageLtMan> I've definitely not delved deep enough to understand what those contexts are going, so far my reasoning goes as far as inference based on function names and where i'm seeing them come up
[01:58:58] <strcat> which asm
[01:59:30] <RageLtMan> Right now i'm trying to work out the overflow protection stuff
[01:59:45] <strcat> that isn't in scope it's being dealt with already
[01:59:55] <strcat> if you mean REFCOUNT
[02:00:21] <RageLtMan> yes
[02:00:30] <strcat> yeah, don't worry about that
[02:00:47] <strcat> the main asm changes that matter are to make the asm RAP compatible
[02:01:06] <RageLtMan> Actually trying to just get a sense of scope and basic functions, trying to let my brain hook whatever knowledge is rolling around in there to get better understanding.
[02:01:13] <strcat> and a lot of that could be figured out from historical diffs between patches when it got introduced
[02:01:42] <strcat> RageLtMan: 50%+ of the stuff in the patch isn't in scope
[02:01:53] <RageLtMan> The paxteam letter from a couple of days ago seemed to mention that current efforts at reference counting had some sort of flaw, one sec, lemme see if i can find it. So i'm hoping to understand what the difference are long as i'm looking at it
[02:02:02] <RageLtMan> ah
[02:02:16] <RageLtMan> RAP is out of scope, or other functionality from pax?
[02:02:21] <strcat> no, I didn't say that
[02:02:32] <RageLtMan> or just the implementation?
[02:02:34] <strcat> legacy functionality isn't in scope, stuff already happening upstream and likely to land isn't in scope
[02:03:51] <strcat> the faster (than upstream) current REFCOUNT implementation in PaX will likely land upstream
[02:04:01] <strcat> there's no reason to extract that separately from the existing work
[02:04:28] <strcat> once it lands, approaching it as opt-out instead of opt-in like PaX can be done with the same infrastructure
[02:04:39] <strcat> or just waiting
[02:05:01] <strcat> not all the atomic_t that can be overflow checked are reference counts though, although it'd be a weird thing to focus on
[02:06:59] <RageLtMan> strcat: in terms to trying to get a sense of the efforts - i'm currently looking at kees' repos (https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/) and yours as the indicators of activity. any place i should add to my scope for upstream/adjacent changes?
[02:08:27] <RageLtMan> regarding refcount, my understanding is that refcount_t is replacing most atomic_t because they're used as counters, while grsec/pax did the opposite and set the ones not used as counters to something else
[02:09:00] <strcat> and I'm saying it isn't in scope because it is being worked on and it needs to be seen what lands upstream to build on that
[02:09:43] <strcat> REFCOUNT is being worked on, it isn't something to worry about yet
[02:09:56] <RageLtMan> gotcha. talk about multidimensional planning... How do you determine which pieces are isolated enough to work on such as to avoid collision?
[02:10:32] <strcat> it doesn't have to do with 'collision' really
[02:10:36] <strcat> it is just already being worked on
[02:10:46] <RageLtMan> Roger.
[02:11:18] <strcat> the high priority is RAP and KERNEXEC page table protections, nothing else is a high priority, since all of the wanted stuff is pretty straightforward (don't mean that it's not a lot of work, but that it's not complex work)
[02:11:27] <strcat> all of the other wanted stuff*
[02:11:27] *** Quits: _andyj_ (uid24906@gateway/web/irccloud.com/x-ahfkkujswkmghilx) (Quit: Connection closed for inactivity)
[02:11:41] <RageLtMan> How does that apply to ASLR? In that letter, paxteam indicated their aslr method not only provides significantly more entropy (though IMO thats a bit of a red herring, its generally infoleaks that kill it), but more importantly avoid memory fragmentation issues.
[02:12:21] <strcat> I didn't mention ASLR
[02:12:25] <strcat> ASLR isn't complex code though
[02:12:51] <RageLtMan> Hence my question - again, trying to wrap head around the scopes and angles this is all dealing with.
[02:13:08] <strcat> you're bringing up a bunch of unrelated stuff
[02:13:33] <strcat> the focus shouldn't be on trivial stuff like changing the ASLR implementation to be at least as good as PaX, it should be on the complex features that are going to bitrot the most
[02:13:53] <strcat> my expectation is that I won't be doing that alone
[02:14:02] *** Joins: syrex (~master@v22016063647935336.nicesrv.de)
[02:14:46] <RageLtMan> Based on the increasing number of people in this chan, and who some of them are from prior interactions, i'd say you're gathering the right kind of interest.
[02:15:01] <strcat> this is more work for me than just maintaining the CopperheadOS kernels, and I'm doing it with the expectation that it's a collaborative project where the time I'm putting in will be dwarfed by the time other people are putting in
[02:15:27] <strcat> okay, but work needs to start, the longer it takes to start, the harder it gets
[02:15:40] <strcat> the last test patch is 4.9, the current kernel is 4.11, and soon enough 4.12 will be out, etc.
[02:16:03] <strcat> the longer it takes for people to decide to start working, the more work and frustration will be involved
[02:16:14] <RageLtMan> Its not feasible for a single person. Things like this need community drivers of some sort - the issues section in GH is a good start, maybe getting people to self-assign here or on github could be a worthwhile effort
[02:16:51] <strcat> it's a theoretical problem until there are people doing the work
[02:17:00] <RageLtMan> Hitting the kernel mailing lists may get people moving too... your argument for "time lost is code lost" is totally valid
[02:17:07] <strcat> once people start seriously working on it, it can be organized more formally
[02:17:12] <strcat> until then, there's nothing to organize
[02:17:41] <strcat> priorities == RAP and KERNEXEC page table prot, but there's a list of other stuff on the issue tracker
[02:17:59] <RageLtMan> You  need people capable of doing the work too... my C skills are a bit short of this (not to say i'm not getting spun up, but i'm a long way off from where you are)
[02:17:59] <strcat> but most things other than those priorities isn't really solving the main issue
[02:18:58] <strcat> if only C knowledge was needed it would be easy
[02:19:02] <RageLtMan> I'll try to pass the good word around, while i myself may not be able to execute this at a level of quality which would let me sleep at night, maybe some of my colleagues who can do it can spare cycles to implement.
[02:19:23] <RageLtMan> There's hardware specific concern as well...
[02:20:07] <strcat> all that's required are capable people willing to dedicate time, there's nothing particularly arcane / magical about this stuff
[02:20:33] <strcat> since those parts are almost all being ignored anyway
[02:22:54] <RageLtMan> Disambiguating the magic from the functional stuff takes a bit of time for the uninitiated. Any way you could mark the red herrings for us newbs? :)
[02:23:50] <strcat> I filed issues in the tracker about features that are wanted, that's done
[02:24:00] <strcat> if there's something else that should be implemented, it can be filed there
[02:24:29] <strcat> the goal is not extracting 100% of the code and moving it over, and breaking it down into components and deciding which ones to take
[02:24:46] <strcat> at least 50%+ is definitely not in scope
[02:24:50] <RageLtMan> I meant more along the lines of "pointers for newbs about whats relevant in the provided patches implementing those features" or if easier "pointers for what to ignore in the public patch"
[02:25:14] <strcat> no, I can't do that
[02:25:17] <strcat> other people can do work
[02:26:03] <strcat> this won't go anywhere if I need to keep taking on more
[02:26:24] <strcat> if people want something, they can do it, regardless of what it is
[02:26:47] <strcat> as I said, by simply maintaining/managing this and doing the forward porting, that's already a lot of my time, and it's invested under the assumption that there are significant contributions made by other people
[02:31:12] <RageLtMan> based on the issue tracker and what i'm reading so far, the kernexec and pax_open_kernel/close thing may be within my grasp
[02:31:54] <strcat> only the page table part is in scope atm
[02:32:21] <strcat> so the baseline functions and page table usage, not the other usage of them with __read_only, because that needs to be adjusted to be upstreamed, and the API will probably be different
[02:32:31] <strcat> you should subscribe to kernel-hardening and follow it
[02:32:48] <RageLtMan> sorry, missed that there even was a list
[02:37:53] <RageLtMan> the openwall list, correct?
[02:37:59] <strcat> yes
[02:38:05] <RageLtMan> done. thanks for the heads up.
[02:38:09] <strcat> follow the list, and read the archives maybe
[02:38:11] <strcat> recent ones at least
[02:38:15] <strcat> better than asking me ;p
[02:41:12] <RageLtMan> You should have gone into medicine... you'd have made a killer corpsman with that cheery bedside manner ;-). In all seriousness though, thank you for taking the time - hopefully we can repay that effort with commits and improvements as we go.
[02:42:24] <strcat> my frustration is that people ask lots of questions, and I try to be helpful, but then there's rarely if ever follow through where work gets done, and my effort trying to do that far outweighs the benefits
[02:43:46] <strcat> I've spend 2.5 years working on a project where it was assumed people would contribute, and it didn't happen, and lots of time was spent trying to make it happen, so I won't me making that mistake in the future - and it is a mistake, because I don't even know that I'm spending my time on the people likely to contribute
[02:43:56] <strcat> so here: change of plan
[02:44:03] <strcat> after someone starts contributing, I will help them
[02:48:37] <RageLtMan> Thats not a bad idea, though should probably be presented in the GH readme - a la "start work on PRs in public, get collaboration, and receive advice from people with heads far less up their ass than you." People only PR-ing things when they believe them to be done is not going to work here.
[02:51:35] <RageLtMan> I get your frustration on the contributor thing, spent countless hours teaching god knows how many people intimate details of things only to have them get confused, throw their hands up because theyre in a rush, and give up. Its abysmally infuriating. The occasional one who sticks and keeps learning is quite often worth the 20 missed ones. Getting one of the tech big-boys to speak in a public way about this would be a huge help too... in case anyo
[02:51:36] <RageLtMan> ne here is in a position to nudge them in that direction.
[02:52:19] <strcat> it's rarely that people got confused it's that they never tried to put serious time into it, beyond asking questions, etc.
[02:52:47] <strcat> not everything is like this, in fact what I'm talking about mostly isn't
[02:53:53] <strcat> if people aren't actually going to follow through on contributing to high-level, application-layer java code, I don't think the chances are going to be better for low-level platform specific C code
[02:54:34] <RageLtMan> Well, in my personal case, the next week is buildbots and packaging for our own DKMS pieces and userspace, but i should at least be able to put in some actual hours toward end of week to try and figure out which of your prioritized issues i can tackle (if any)
[02:55:20] <RageLtMan> Sorry, not tracking - Java?
[02:55:25] <strcat> nvm
[02:56:03] <RageLtMan> Take a look at openzfs as an example of weird kernel code which gets tons of contribution. its doable, it requires a community to build the momentum
[02:56:50] <RageLtMan> intel and a number of other vendors are pushing to the linux branch, with a ton of that getting upstreamed through a complex process into other OS'. lots of turning gears and lots of people, but its doable
[02:59:14] <strcat> all I'm going to do is facilitate there being an updated tree to do work for, not doing it all or doing mentoring/outreach
[02:59:25] <strcat> as always, someone can step up and do what they think is important
[03:03:20] <RageLtMan> To think, users believe there are thousands of people like you who are well paid by their companies to do this. Governments and companies apparently have no interest in funding a secure execution context - that letter paxteam wrote indicates theyve never even been approached to upstream. The politics of that debate are well over my head, but from what little i do get, it has something to do with Linux maintainers not wanting to alter core componen
[03:03:20] <RageLtMan> ts for the sake of security, and dependent users (companies) not wanting to pay anyone (hence the closing of the sources in the first place).
[03:38:16] *** Joins: catpigger (~catpig@p54A57AFB.dip0.t-ipconnect.de)
[03:41:55] *** Quits: catpig (~catpig@p54A5789E.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
[03:42:12] <nmatt> RageLtMan: as far as "help for noobs" I definitely would put myself in the category of noob. Hop on the mailing lists, pick a feature from grsec and start grep'ing through a grsec patched kernel and try to understand how it works.
[03:43:20] <nmatt> but I would like to provide some basics to getting started in the form of a blog post or something.
[03:44:12] <RageLtMan> nmatt: please! Blog posts, wiki entries, issues, anything to help bootstrap newcomers. Need to think like pushers - get people hooked somehow
[03:46:43] <nmatt> will do. also I'm almost done revamping the wiki conversion
[03:47:36] <RageLtMan> I would love to find a way to amicably engage the grsec people - they're working on their next-gen stuff, probably wouldn't mind not having to maintain forward porting of a bunch of this stuff if they were properly compensated to help upstream it. If i'm reading the paxteam letter correctly, they basically left the door open to someone making them a realistic offer to do the work (at least thats how i understand the section regarding upstreaming e
[03:47:36] <RageLtMan> fforts)
[03:48:23] <RageLtMan> *sigh* and silicone valley is investing hundreds of millions into trendy juicers, while infosec efforts are basically penalized.
[03:48:58] <strcat> if you think they want compensation to get it upstreamed, you're misunderstanding spender
[03:49:20] <strcat> spender doesn't want money, fame or a lower maintenance burden
[03:49:39] <strcat> I have no idea what he wants, but it's definitely not that
[03:50:46] <RageLtMan> again, politics a bit over my head, but paxteam is a separate person/people, right?
[03:51:04] <strcat> yes and extremely loyal to spender
[03:51:06] <nmatt> they work together I think
[03:51:17] <strcat> they are 2 people but they aren't separate entities in terms of getting one to do something the other doesn't want to do...
[03:51:23] <strcat> they make decisions together
[03:51:40] <RageLtMan> I wouldnt suggest trying to separate them, simply that the tone of response seems different, i cant speak to content - havent seen much from spender on all this
[03:52:58] <nmatt> http://www.openwall.com/lists/kernel-hardening/2017/05/11/2
[03:53:12] <nmatt> pax team shares the same tone
[03:53:16] <strcat> RageLtMan: https://github.com/thestinger/linux-hardened/commit/2929f2d18b3a1f73f8d161c5886f7b5ee01455d3#commitcomment-22134970
[03:53:21] <strcat> good luck cooperating with spender
[03:53:58] <strcat> I'm accused of 'plagiarism' for stumbling on this bug when I added the leading 0 byte to the canaries, which I only did because I implemented heap canaries and it was related
[03:54:46] <strcat> meanwhile, the earliest public mailing list post from 2007 about it that *he links to* does not mention PaX
[03:55:05] <strcat> the patches he's saying fixed it earlier are not even publicly available
[03:55:29] <strcat> how the hell am I supposed to know that they fixed the bug in jan 2007? the earliest pax patch I see is august
[03:55:32] <RageLtMan> huh, i'd have thought theyd be supporting coppherhead full-on
[03:55:43] <strcat> earliest public mention is june, which is earlier
[03:55:53] <strcat> RageLtMan: uh, no, spender has never supported us even when we were on good terms
[03:55:58] <strcat> we could never find a way to work with him
[03:56:22] <strcat> I asked if he'd accept a full time job working on grsec where he got paid well and still had full control
[03:56:24] <strcat> he said no
[03:56:31] <strcat> so tell me, what does he want?
[03:57:00] <strcat> he didn't want to work with us, he didn't want us to get him a full time job working on grsec, he didn't want to work with citizen lab
[03:57:08] <strcat> anything involving money he hasn't been interested in
[03:57:24] <strcat> and then earlier, when I asked about funding certain work, he implied that there wasn't time to do it all unless there was enough money for full time work
[03:57:31] <strcat> but then he was unwilling to do full time work for 1 company
[03:57:46] <RageLtMan> Wasn't he w/ accuvant till they were bought out?
[03:57:48] <strcat> it needs to be something like the linux foundation with say 10+ different companies pooling money or he won't do it
[03:57:51] <strcat> RageLtMan: that isn't grsec
[03:58:00] <strcat> sure he is not unemployed
[03:58:07] <strcat> his full time job is not grsec, and never has been
[03:58:32] <strcat> anyway, there is no working with spender, there is only purchasing their products, and they don't seem very interested in actually selling them
[03:58:47] <strcat> try having your company get a commercial grsec license atm
[03:58:48] <RageLtMan> infosec research i imagine given the leanings... if not straight up red team practice
[03:58:58] <strcat> seriously, try
[03:59:06] <strcat> have your company contact grsec sales
[03:59:19] <RageLtMan> i'm trying to get a private one - this mess screwed us BAD. we just got people to start TRYING grsec kernels in builds for upcoming projects
[03:59:22] <strcat> for 1) the patches, 2) RAP (which is more hilarious)
[03:59:29] <strcat> RageLtMan: ok, so you'll see
[03:59:36] <strcat> have you contacted them yet?
[03:59:49] <RageLtMan> yeah, but what they're suggesting doesnt quite work for us
[03:59:58] <strcat> after you contact them, you'll understand
[04:00:01] <strcat> especially if you ask about RAP
[04:00:01] <RageLtMan> we actually dont need the stable as much as the test because we're working on systems a year or two out
[04:00:12] <nmatt> how much for RAP?
[04:00:56] <strcat> more than I earn in a year
[04:00:58] <RageLtMan> ironically for this hospital project we cant use RAP - cluster of GPU compute boxes with docker containers from nvidia using their proprietary driver, so in our internal testbeds we build without it. We use RAP on our virtual images in our private cloud and on the control/compute nodes
[04:01:19] <nmatt> lol
[04:01:33] <strcat> jduck: do you remember how expensive RAP was
[04:01:33] <RageLtMan> the problem i have now i that even if i do get a set of patches to work with, i wont be able to test them on the hospital's systems until THEY buy a license, without having been able to test it
[04:01:35] <RageLtMan> its a nightmare
[04:01:37] <strcat> jduck: it's probably more now tho
[04:02:10] <strcat> nmatt: 85k USD / year
[04:02:20] <strcat> nmatt: and I think you get 2 support questions a year, or something like that
[04:02:37] <nmatt> isn't that generous of them
[04:02:46] <RageLtMan> thats literally a rounding error for companies running medical devices with exposed interfaces or other critical infrastructure.
[04:02:48] <strcat> and they haven't sold it to anyone yet afaik
[04:02:54] <strcat> I don't think they want to
[04:03:07] <strcat> seriously I almost believe that they'll just raise the price high enough that they think you won't pay
[04:03:12] <strcat> I don't really think so
[04:03:26] <strcat> but I wouldn't be surprised if it cost a lot more than 85k/year if it was a bigger company asking
[04:03:34] <strcat> it's only for a small company that 85k/year has been offered
[04:03:46] <strcat> (companies totally unable to pay that...)
[04:03:46] <RageLtMan> whats a compromise cost when you lose PHI on a large scale? the stock price hit alone is more than any RAP license
[04:04:27] <RageLtMan> is there even a licensing model around what you guys do? you wouldn't be able to distribute the devices, right?
[04:04:48] <strcat> RageLtMan: there is no point of us licensing stuff from them for CopperheadOS for multiple reasons
[04:05:00] <strcat> it wasn't us that tried
[04:06:10] <strcat> anyway, I don't like spender much anymore, he's been a dick to me since before any of these recent events
[04:06:21] <RageLtMan> With my pro-services hat on, my take is "evaluate options, determine best of breed within operating constraints, implement/recommend." This mess has created constraints i dont even fully grasp yet, but theyre mostly in the business logic and result in a massive decrease in security posture.
[04:06:51] <strcat> he liked me before Copperhead, but after that he said bad things about me to a journalist behind my back - while I was still going out of my way to support them, and I still did after, I just shrugged and moved on from that
[04:07:01] <strcat> anyway
[04:07:08] <strcat> no one else is allowed to work on anything
[04:07:09] <RageLtMan> I sort of got the sense that industry sees the guy as a dick who's right.
[04:07:19] <strcat> he's often right
[04:07:21] <strcat> not always
[04:07:23] <strcat> similar to linus
[04:09:30] <RageLtMan> The ripple effects of all of this will haunt us for the next decade. If this project takes off, it will help more people than grsec for the simple fact of being built-in, if it dies on the vine, literally everyone on the planet will be paying in one way or another.
[04:10:45] <RageLtMan> I cant see a lot of these companies who have to be forcibly pushed into thinking about security by a red team guy slapping them with their clear text passwords in a leather-bound tome taking the effort to work out licensing with all the constraints and uncertainty - they'll see it as a large business risk.
[04:19:01] <yrp> I thought this was supposed to the be channel free of this endless bitching strcat =p
[04:19:31] <strcat> yrp: yeah well spender is actively bothering me
[04:19:38] <strcat> yrp: and it wasn't me that said that ;p
[04:20:20] <yrp> 20:21 <yrp> is there somewhere I can go where people talk about the technical components of grsec/kernel security? i just dont care about if its open or not.
[04:20:22] <yrp> 20:21 <strcat> yrp: freenode ##linux-hardened
[04:20:24] <yrp> =p
[04:21:33] <kees> I think it's worth noting anything technical offered by spender and to ignore everything else. the politics are tiring at this point.
[04:22:04] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[04:22:30] <strcat> kees: yeah but he's willing to make statements that are technically accurate but very misleading
[04:22:41] <strcat> sometimes *barely* technically accurate
[04:22:52] <kees> right
[04:23:08] <strcat> like saying X upstream is 'broken' but not wanting to say why, and then it turns out to me something you already knew and that isn't compelling
[04:23:14] <strcat> like saying VMAP_STACK is broken / insecure
[04:23:29] <kees> I mean, that's basically how he and I first met. he flamed me on my blog about emulated NX technicalities. :P
[04:23:40] <kees> right
[04:24:01] <strcat> yrp: well https://github.com/thestinger/linux-hardened/commit/2929f2d18b3a1f73f8d161c5886f7b5ee01455d3#commitcomment-22134970
[04:24:11] <strcat> yrp: https://github.com/thestinger/linux-hardened/commit/09262ec80091c27c21171c7e90e30c1de9e38b3a#commitcomment-22134962
[04:24:17] <strcat> it's on my repo, not somewhere else
[04:24:19] <strcat> ;\
[04:24:31] <yrp> i dont care
[04:24:42] <yrp> like, fine if you guys are going to bitch about it here too whatever
[04:25:07] <strcat> it's spender coming to my repo and whining about nonsensical stuff, lets me clear about that
[04:25:12] <strcat> s/me/be/
[04:25:38] <strcat> 'in more complete form'
[04:25:49] <yrp> is there -another- channel where people interested in kernel security hang out where its not endelss bickering about who said what mean or misleading thing?
[04:25:57] <kees> he's going to be a reality in this project, so it's best to figure out how to manage his interjections appropriately. it may even end up becoming a FAQ entry on the wiki
[04:26:22] <kees> yrp: spender will find it and try to ruin it too, so let's stay here and just ignore it.
[04:26:26] <strcat> kees: not necessarily I could move the repo to copperhead and just ban him ;p
[04:26:29] <strcat> orgs can ban people
[04:26:38] <yrp> I just dont give a fuck if spender is an asshole. Linus is a famous asshole, and people seem to work with him just fine.
[04:27:01] <kees> they both drive people away. :( but for those that put up with it, it's ignorable.
[04:27:08] <kees> strcat: yeah, if it comes to that.
[04:27:44] *** Quits: somis (~somis@149.56.153.184) (Quit: WeeChat 1.7.1)
[04:27:56] <strcat> yrp: linus is not really an 'asshole' though, he likes flame wars / bickering and is a bit rude - I've never seen him really be a dick to someone, beyond flaming them and I doubt he does that irl
[04:28:20] <strcat> and he sticks a lot more to technical criticism even when he's rude about it
[04:29:26] <strcat> he's not going to send me an email saying I'm a worthless, unintelligent waste of space with 0 integrity because I didn't swear at kees for him, which is probably something he'd like just like spender
[04:30:44] <strcat> worth noting I was on good terms with spender to the point that he'd tell me stuff that wasn't public in PMs until very, very recently
[04:32:03] <yrp> Cool. So if anyone else here knows cool spots where peopel discuss kernel security shit and isnt a dystopian version of high school where everyone has worse social skills somehow, please hit me up.
[04:32:48] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[04:33:37] <strcat> kees: https://github.com/thestinger/linux-hardened/commit/e6c5ea972e1188eeb3a43b03d338e2a7b3a37fc1.patch
[04:33:40] <strcat> kees: the new version btw
[04:33:48] <strcat> kees: covers strlcpy and has the compile-time errors split
[04:34:08] <strcat> just haven't heavily stared at it and tested it yet
[04:37:29] <kees> strcat: awesome, thanks!
[04:41:36] <kees> strcat: ooh, I love the strlen coverage :)
[04:42:39] <strcat> kees: yeah and easy to reuse it, strncat uses both strlen/strnlen and relies on those existing checks
[04:43:08] <strcat> kees: it might be possible to do string compile-time checks but it's kinda annoying and might not find anything
[04:43:16] <strcat> need to do __builtin_constant_p(__builtin_strlen(s)) maybe
[04:43:20] <strcat> then use __builtin_strlen(s)
[04:43:53] <strcat> anyway not super important, since anything caught at compile-time will be caught when the code actually runs if there isn't a compile-time check
[04:43:57] <strcat> it's just nice for productivity
[04:44:35] <strcat> it'd have been annoying to find those memcpy instead of strncpy cases slowly over time, for example
[04:44:44] <strcat> but I'm sure there's other stuff like that not caught at compile-time ;p
[05:07:14] <kees> I only worry about runtime false positives. :(
[05:08:30] <strcat> kees: that's mostly from using __builtin_object_size(p, 1) though, I don't think this should catch anything that's not undefined
[05:09:01] <strcat> kees: this is all __builtin_object_size(p, 0) for now, so no intra-object checks, which is where false positives come from
[05:09:15] <strcat> there can be a FORTIFY_SOURCE_STRICT later
[05:10:11] <strcat> I'm not 100% clear on which stuff is actually a false positive with the stricter mode vs. genuinely undefined, so not going to propose that until I can actually explain it properly (which glibc, etc. don't seem to do they just say _FORTIFY_SOURCE=2 'can' cause false positives while _FORTIFY_SOURCE=1 shouldn't)
[05:14:29] *** Joins: warsh (~warsh@unaffiliated/warsh)
[05:17:55] *** Joins: kerframil (kerframil@gentoo/user/kerframil)
[05:23:17] <nmatt> wiki now looks better: https://github.com/thestinger/linux-hardened/wiki
[05:25:37] <nmatt> strcat: let me know what you want changed on the wiki in order to make it "official"
[05:26:08] <strcat> nmatt: it might be fine now, /r/linux was just being irritating and I shooed them away
[05:26:23] <nmatt> cool
[05:27:10] <strcat> nmatt: https://www.reddit.com/r/linux/comments/6ag9nd/the_hardened_kernel_project_is_working_on_getting/dhecyo9/
[05:27:51] <nmatt> oh wow... didn't see that
[05:28:26] <strcat> nmatt: https://www.reddit.com/r/linux/comments/6ag9nd/the_hardened_kernel_project_is_working_on_getting/dhfahc3/ and more nonsense
[05:28:27] <strcat> cause /r/linux
[05:28:34] <strcat> nmatt: that's when I added that, to shoo them away
[05:29:19] <nmatt> yeah and we don't have that bit about stability anymore
[05:30:38] *** Quits: citypw (~citypw@207.226.142.235) (Quit: Leaving)
[05:32:30] <strcat> kees: I could switch it to BUG
[05:32:54] <strcat> kees: it ended up like this b/c BUG can't be used in that header
[05:33:23] <strcat> could rename fortify_panic -> fortify_error and print error + BUG or w/e
[05:43:23] *** Joins: N8Lord (~n8fear@p5DD14A0F.dip0.t-ipconnect.de)
[05:46:06] <kees> strcat: the nice thing about BUG is that it isn't strictly a panic.
[05:46:36] *** Quits: n8fear_ (~n8fear@p57923D26.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
[05:46:44] <strcat> kees: yeah and I'm fine with using BUG, I'll do it for the next version
[05:46:51] <strcat> kees: but it needs a fortify error symbol
[05:47:11] <strcat> also BUG prob isn't available in some of that early code
[05:47:23] <strcat> (in addition to the wonderful cyclical header dep thing that'd happen ;p)
[05:47:31] <strcat> can just replace the panic with it
[05:55:45] <RageLtMan> strcat: on the bright side, spender's doing free code review ;)
[05:56:01] <strcat> no, he's not
[05:56:14] <strcat> if he finds a problem, he won't say so, he'll give you a hash
[05:56:25] <strcat> if he makes an actual statement, it's because it's not helpful
[05:56:47] <strcat> and he's being deliberately misleading in his statements there so I don't really see how that's code review
[05:58:18] <RageLtMan> Was hoping it was along the lines of "gruff but informative" - only saw the two comments you showed. Does GH have a good way just to show comments on a repo's commits?
[05:59:26] <strcat> no, it's unhelpful, unproductive, misleading claims
[05:59:28] <strcat> not code review
[05:59:46] <strcat> RageLtMan: no
[05:59:54] <strcat> I linked everything he posted
[06:01:04] <RageLtMan> Since the start of this mess i've seen lots of references to terms like misleading, lies, etc. For those of us not deeply familiar with the semantics and history around all of this, its pretty much impossible to disambiguate without hundreds of hours of commit review
[06:01:32] <RageLtMan> i've no idea whats what at this point :). Seems to be the theme of 2017
[06:01:56] <strcat> so then look at what I linked
[06:02:14] <RageLtMan> Discussions seem to focus on who implemented what and when across a number of articles, mailing lists, etc, but i'm not sure what any of that has to do with the how aspect of the kernel as it stands today (4.9+ lets say)
[06:02:17] <strcat> there's nothing subjective or ambiguous about it
[06:02:42] <RageLtMan> It seems he's pointing out that he has already done this, which is great, but now that its not public, its sort of a moot point.
[06:03:12] <strcat> RageLtMan: he hasn't done it
[06:03:22] <strcat> he did something similar, but different, that was never included in the grsecurity patches
[06:03:40] <RageLtMan> Making it all the more confusing why its brought up.
[06:03:47] <strcat> and he makes an untrue claim that what he did is broader / covers more, based on being manipulative about me not including alloc_size in the same commit
[06:03:50] <strcat> RageLtMan: there is nothing confusing
[06:03:54] <strcat> you can see my code, you can see his code
[06:03:58] <RageLtMan> far as i understand what you're doing, is you're pushing pieces of the hardening stack from copperhead up
[06:04:27] <RageLtMan> in this case the gcc fortification relevant pieces
[06:05:04] <strcat> it's improved upon since the initial implementation in CopperheadOS, and either way it's not the same as any previous implementation
[06:05:16] <strcat> which, if you read the commit message, look at the code, and look at what he linked, is obvious
[06:05:22] <strcat> there is nothing subjective there
[06:05:27] <RageLtMan> that part im seeing - the differences
[06:06:27] <strcat> in fact it explains in the commit message how it's different than the glibc approach, and it's easy to see that the linked code is the glibc approach (chk functions, not inline, only checking for write overflows, not reads - and not covering as much of these)
[06:06:56] <strcat> so, lets not pretend this is a matter of opinion, I'm not going to tolerate that
[06:07:12] <strcat> it's spender unjustifiably being a manipulative dick, there is no technical value to what he said
[06:07:18] <RageLtMan> their implementation seems very different, you're covering strings here
[06:07:50] <RageLtMan> whats the purpose of that behavior? I guess i'm having trouble understanding why someone would go through that trouble
[06:08:18] <strcat> because he's been incredibly pissed off at me for mentioning that useroffset/usersize were added as new features to PaX USERCOPY in the public patches
[06:08:35] <strcat> that's why he banned me, that's why he repeatedly antagonizes me in both public / private now
[06:09:55] <RageLtMan> define public patches in this context - you mean added by someone outside the team and pulled back in by them, or things they added only to the public patches for some reason?
[06:10:30] <strcat> I'll restate what I said
[06:10:51] <strcat> I posted to a kernel thread mentioning that a PaX feature existed, that is part of the public PaX and grsecurity patches
[06:11:08] <strcat> spender considered that to be "leaking" information to 'evil' upstream
[06:11:17] <strcat> information that anyone can see by looking in the patch
[06:11:20] <strcat> so I was banned for it
[06:11:25] <strcat> I can give you his own words, if you want that
[06:12:08] <RageLtMan> all set, got the context. still confused as hell, but understand what transpired
[06:12:17] <strcat> 2017-05-11 19:20:39 strcat I do argue your side of things sometimes but I'm not going to spend all my time doing that
[06:12:19] <strcat> 2017-05-11 19:21:02 strcat the mailing list thread you banned me for mostly involved criticizing them
[06:12:21] <strcat> 2017-05-11 19:21:28 spender nah you leaked stuff
[06:12:23] <strcat> 2017-05-11 19:21:34 strcat 'leaked'
[06:12:25] <strcat> 2017-05-11 19:21:36 strcat it's in a public patch
[06:12:33] <RageLtMan> im starting to think i understand linux culture far less than its mechanisms
[06:12:34] <strcat> 2017-05-11 19:23:59 spender was talking about you leaking a bunch of stuff they hadn't noticed
[06:12:36] <strcat> 2017-05-11 19:24:09 spender like, there was no reason for it
[06:12:38] <strcat> 2017-05-11 19:24:23 spender aka it was contributing to their plagiarism
[06:13:05] <strcat> well, you keep making it seem like there are 2 reasonable sides to this and making me dump more explanations / info here vs. doing something useful
[06:13:33] <RageLtMan> i appreciate you filling me in, just seems like madness all around. how is there plagiarism in a gplv2 project?
[06:13:55] <strcat> he considers it plagiarism / stealing to take code from grsecurity, and upstream it, even if you give full credit about where it came from
[06:14:05] <RageLtMan> use without attribution? It all sounds weird in the GPL world.
[06:14:12] <strcat> use *with* attrition
[06:14:14] <RageLtMan> oh.
[06:14:15] <strcat> attribution
[06:14:23] <strcat> and if you give credit, he considers that abusing the brand / reputation of his project to peddle inferior stuff
[06:15:00] <strcat> so, most people have given credit, so he's mad about 1) plagiarism (despite there being credit, and it being GPL2), 2) abusing his brand to promote their stuff, by saying "based on work in grsecurity" in the commit msg
[06:15:13] <RageLtMan> is that because some embedded vendor ripped them off, or does this thought process predate that? There's also the "what happens to grsec and its benefits if spender is hit by a bus?" concern
[06:15:30] <strcat> he wasn't unreasonable as hell like this in the past, it's a recent thing
[06:15:43] <strcat> he was never like this 2+ years ago
[06:15:58] <strcat> in fact he tried to convince upstream to implement the stuff in grsecurity
[06:16:07] <RageLtMan> engineers burn out every once in a while... they tend to get pretty angry during those periods
[06:16:18] <strcat> doesn't have to do with that
[06:16:31] <strcat> some companies did unethical stuff, and he projects that onto anyone working on upstream code now
[06:16:36] <strcat> guilt by association
[06:17:16] <RageLtMan> from what i recall of the original post about the stable series, they tried to defend their trademark and were told to go screw by the courts. maybe he feels the system failed them
[06:17:23] <strcat> that has nothing to do with me
[06:17:47] <strcat> or other people deriving changes to submit upstream from his GPL2 code and giving full credit to him
[06:18:03] <RageLtMan> not saying it does, or kees, or anyone else. just trying to piece together whats going on, the players, and motivations. that last part is eluding me completely.
[06:19:04] <RageLtMan> That commit for the string functions is quite educational, thanks :)
[06:21:39] <RageLtMan> so basically consumers which for some reason do bad things with strings can still explicitly call out the unsafe functions, but it will require developers change their code to do this and are at least aware of the error
[06:22:28] <strcat> the compiler tries to detect buffer sizes for both src/dst buffers and inserts runtime checks to detect overflows, along with giving compile-time errors when the size is constant
[06:24:03] <strcat> so if you do 'char buf[40]; strcpy(buf, s);' it will essentially replace that with 'char buf[40]; if (strscpy(buf, s, 40) < 0) abort();', etc.
[06:24:42] <strcat> it covers the mem* functions in string.h and most of the str* functions, both reads and writes
[06:26:54] <strcat> it's a small feature, but it finds / mitigates a decent number of bugs, so it's useful, and it was a good way to start on upstreaming stuff
[06:30:02] <strcat> small and very cheap performance-wise
[06:31:18] <strcat> there are already a dozen little bugs fixed because I decided to work on it, and it didn't take much time to make, but really, there is tons of more important stuff to work on it and I don't want to focus on that just because someone is being an idiot about it
[06:37:26] <RageLtMan> thank you, both for the work and explanation :)
[06:38:32] <RageLtMan> ive been keeping our own arch packaging for kernel with grsec stuff, updated it to use the unofficial 4.9 patches and the only thing which broke was the need to add a hook to update grub for the missing grsec string. good god i love Arch packaging
[06:41:57] <RageLtMan> havent decided yet what the hell i'm to do about our own stable repo... so far this is only in testing, but eventually im going to have make a call on whether to try and compose things from hardened and kspp or try to move forward on minipli's stuff if i can't work something out with grsec for licensing.
[06:42:26] <RageLtMan> i wonder what the alpine people are doing...
[06:46:08] <RageLtMan> as a complete aside, i have a technical question: i've observed situations where unsafe memory operations in kernel modules of KVM instances are apparently caught by the hypervisor's grsec kernel. usercopy issue with an skb from netfilter. we never caught the bug until i ran a vm on a grsec patched host. It didnt log to dmesg on the host, but consistently crashed the kernel module in the VM, only on grsec hosts... how is this possible? I was under
[06:46:08] <RageLtMan>  the impression that KVM didnt paravirt operations outside of IO
[06:59:01] *** Quits: White_Light (~Spacemen_@cpe-108-167-11-28.neb.res.rr.com) (Quit: Leaving)
[07:05:04] *** Joins: White_Light (~Spacemen_@cpe-108-167-11-28.neb.res.rr.com)
[07:11:07] <strcat> https://github.com/thestinger/linux-hardened/issues?q=is%3Aopen+is%3Aissue
[07:11:10] <strcat> there all labelled
[07:11:25] <strcat> need to figure out rest of stuff that's considered in-scope now
[07:16:28] <RageLtMan> thank you strcat
[07:16:37] <RageLtMan> btw, regarding the alpine piece: (47/56) Installing linux-hardened (4.9.27-r1)
[07:16:57] <RageLtMan> looks like they changed the name too, and by that version number i'm assuming the minipli patches
[07:23:20] *** Quits: polyzen (~dmc@unaffiliated/polyzen) (Remote host closed the connection)
[07:25:31] *** Joins: dmc (~dmc@unaffiliated/polyzen)
[07:25:38] *** Quits: dmc (~dmc@unaffiliated/polyzen) (Remote host closed the connection)
[07:27:48] *** Joins: dmc (~dmc@unaffiliated/polyzen)
[07:49:22] *** Quits: catpigger (~catpig@p54A57AFB.dip0.t-ipconnect.de) (Quit: Leaving)
[08:02:35] *** Quits: kerframil (kerframil@gentoo/user/kerframil) (Quit: Leaving)
[09:22:20] *** Quits: strcat (~strcat@archlinux/trusteduser/thestinger) (Quit: WeeChat 1.7.1)
[09:59:44] *** Quits: N8Lord (~n8fear@p5DD14A0F.dip0.t-ipconnect.de) (Quit: WeeChat 1.7.1)
[10:29:14] *** Joins: b0untea (~b0untea@LStLambert-657-1-110-45.w92-154.abo.wanadoo.fr)
[10:37:56] *** Quits: dave0x6d (uid190567@gateway/web/irccloud.com/x-gguacgqtiweapebb) (Quit: Connection closed for inactivity)
[11:54:37] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[13:17:01] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[13:30:13] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[13:47:59] *** Joins: aissen (~aissen@unaffiliated/aissen)
[13:48:06] <aissen> yeah :-)
[15:15:19] *** Joins: umoot (d598a145@gateway/web/freenode/ip.213.152.161.69)
[15:18:06] <umoot> Hi! Anyone can confirm this behaviour? https://github.com/thestinger/linux-hardened/issues/27
[15:31:34] <aissen> umoot: can you bisect it ?
[15:31:44] <aissen> umoot: is it systematic ?
[15:32:44] <umoot> aissen: it's always reproducible on my machine
[15:32:54] <aissen> umoot: finally, there might be a way to have logs with netconsole/serial console. But if it's easy to reproduce it would be faster to bisect.
[15:33:28] <aissen> umoot: oh, I see I asked you to bisect, but you didn't say if it's panicking on all linux-hardened tags
[15:33:34] <aissen> umoot: did you try just one version ?
[15:34:36] <umoot> aissen: as I wrote in issue description it happens with newest 4.11.1.a version. All previous versions were ok
[15:35:05] <umoot> aissen: vanilla 4.11.1 is also ok
[15:35:07] <aissen> umoot: oh, that's good to know. Do you know how to run a git bisect ?
[15:35:30] <umoot> aissen: unfortunately, no...
[15:35:54] <aissen> umoot: wait a minute
[15:37:28] <aissen> umoot: you can try reading https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git
[15:37:50] <aissen> bisection should only take 4 or 5 compilations and reboots, if you have time
[15:38:32] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[15:39:54] <aissen> umoot: so you last booted with 4.11.f and suspend worked ?
[15:41:02] <umoot> aissen: yes 4.11.f works, 4.11.1 without hardened patch works too
[15:41:08] <aissen> umoot: so it should be roughly 7 steps according to what I'm seeing here
[15:42:06] <aissen> roughly 5 steps
[15:44:41] <aissen> umoot: So you do a "git bisect start 4.11.1.a v4.11.1 4.11.f" ; then compile, and if suspend/resume works you do a "git bisect good" , if it resume crashes you do a "git bisect bad". Then post the log of what you did to a pastebin so someone can look into it.
[15:45:48] <umoot> aissen: ok I'll look into it, thank you
[15:49:19] *** Joins: catpig (~catpig@p54A57AFB.dip0.t-ipconnect.de)
[15:58:21] <jduck> weeee
[16:03:38] <jduck> where is strcat... hrm....
[16:21:07] <Shiz> sleeping probably
[16:47:24] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[16:49:48] *** Joins: dave0x6d (uid190567@gateway/web/irccloud.com/x-ryqhvjoqdgrjvdfb)
[17:01:34] *** Quits: tigrmesh (~tigrmesh@archlinux/op/tigrmesh) (Ping timeout: 255 seconds)
[17:04:04] *** Joins: citypw (~citypw@207.226.142.235)
[17:15:47] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[17:37:20] <aissen> timezones are a bitch
[17:37:32] <aissen> err, a pain
[17:44:20] *** Quits: peetaur2 (~peter@i4DF67CD2.pool.tripleplugandplay.com) (Ping timeout: 260 seconds)
[17:46:45] *** Joins: strcat (~strcat@archlinux/trusteduser/thestinger)
[17:46:45] *** ChanServ sets mode: +o strcat
[18:01:39] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[18:04:32] *** Joins: _andyj_ (uid24906@gateway/web/irccloud.com/x-jyqhwwjhttrhcozn)
[18:43:32] *** Joins: somis (~somis@149.56.153.182)
[18:52:15] *** Joins: tigrmesh (~tigrmesh@archlinux/op/tigrmesh)
[19:03:37] <strcat> kees: I can't use BUG because I need fortify_panic to be noreturn to generate sane code
[19:03:58] <strcat> so I need a way to do an oops that's noreturn
[19:04:06] <strcat> for some reason BUG can be turned off
[19:04:42] <strcat> it's fine to do a kernel oops if there's a way to do it that always ends the current thread
[19:05:55] <strcat> is BUG noreturn when CONFIG_BUG is turned on at least?
[19:06:17] <strcat> it looks fairly per-arch and I don't know which if any guarantees I have from it
[19:12:14] <kees> Hmm, good point about BUG
[19:12:19] <kees> it _should_ be noreturn, though.
[19:12:25] <kees> that's not something I've dug into yet
[19:12:36] <strcat> kees: I think I'll leave it as is and I can explain that if anyone asks
[19:12:36] <kees> it kills the current kernel thread of execution, though. hmpf
[19:12:39] <kees> yeah
[19:12:41] <kees> agreed
[19:13:10] <strcat> kees: it might make sense to have a debug mode where it is not noreturn and warns instead of using panic *or* BUG
[19:13:41] <strcat> I think someone found an issue caught by the fortified strlcpy on resume
[19:13:45] <strcat> https://github.com/thestinger/linux-hardened/issues/27#issuecomment-301539817
[19:13:47] <strcat> I'll see
[19:16:27] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[19:16:37] <kees> __NO_FORTIFY on the resume code maybe?
[19:17:02] <strcat> kees: I'll give them a patch making it only warn
[19:19:00] <Lionel_Debroux> kees: I have mostly prepared another patch like the two I sent over the week-end to kernel-hardening, but unlike these two, the base code has changed between 4.11 and 4.12-rc1. Which tree should I target ? linux-next ?
[19:22:05] <strcat> Lionel_Debroux: at a minimum do work based on linus' master branch, which is where the mainline tags are made
[19:22:15] <strcat> depends on the workflow for the code you're working on
[19:22:29] <strcat> but you're always at least targeting master
[19:23:47] <kees> Lionel_Debroux: if possible, use Linus's last release (v4.11 in this case). when it's something fast-moving or under lots of work, basing it off a specific linux-next tag is next-best. The latter can make merging hard, but it really depends on the code.
[19:24:03] <kees> I'm digging myself out from under email right now, I'll try to find what you sent
[19:27:05] *** Quits: b0untea (~b0untea@LStLambert-657-1-110-45.w92-154.abo.wanadoo.fr) (Quit: Leaving)
[19:27:29] <strcat> kees: last release by linus would be the rc though, or really just master where the tags are made
[19:27:31] <strcat> *shrug*
[19:27:47] <strcat> next is a PITA
[19:27:58] <strcat> it's probably already broken without your help ;)
[19:32:12] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[19:33:07] <Lionel_Debroux> For now, I wrote it against Linus master, which was 4.12-rc1 at the time.
[19:34:21] <Lionel_Debroux> It's another companion change for RAP.
[19:35:01] <kees> strcat: it can get complex. best is base release (v4.11). next best is v4.12-rc2, then v4.12-rc1, then -next
[19:35:40] <strcat> kees: why is 4.11 better than current master / rc ?
[19:35:42] <kees> e.g. I keep my trees for -next based on the last -rc2
[19:36:06] <strcat> the 'stable' releases are just another rc really
[19:36:08] <kees> strcat: FWIU, Linus likes doing merges from there for new things.
[19:36:12] <strcat> ah
[19:36:19] <kees> ignore stable for basing "new" stuff
[19:36:37] <kees> for making sfr's job easiest for -next merges, -rc2 is after the merge window has flushed
[19:36:49] <kees> -rc1 is kind of still "in the middle of lots of stuff going in"
[19:37:00] <kees> and -next is a moving target
[20:34:39] *** Joins: b0untea (~b0untea@78.192.96.126)
[20:43:52] *** Quits: b0untea (~b0untea@78.192.96.126) (Read error: Connection reset by peer)
[20:54:41] *** Joins: ph4nt0m[m] (hiyasibnsk@gateway/shell/matrix.org/x-hpvojtrbvesjhkce)
[20:55:51] <strcat> kees: unfortunately the error messages get a bit weird for strlcpy
[20:55:58] <strcat> since they come from memcpy or w/e
[20:56:16] <strcat> I need to tweak it anyway, the memcpy check isn't quite enough
[20:57:50] <kdave> BUG is effectively __builtin_unreachable and applies to the control flow branch rather than the whole function
[20:58:11] <strcat> kdave: yeah but it isn't guaranteed to be __noreturn
[20:58:21] <kdave> strcat: indeed
[20:58:24] <strcat> kdave: and I need that to use it in a __noreturn function to make it satisfy that
[20:58:45] <strcat> unless I make it conditional on CONFIG_BUG, but I don't think BUG is guaranteed to work sanely per-arch
[20:58:48] <strcat> what if an arch just warns?
[20:58:50] <kdave> strcat: can you point me to the code?
[20:59:12] <strcat> kdave: https://github.com/thestinger/linux-hardened/commit/e6c5ea972e1188eeb3a43b03d338e2a7b3a37fc1
[20:59:19] <strcat> fortify_panic
[20:59:23] <kdave> I was curious about the BUG wrt noreturn relation so I may not have the right context
[20:59:53] <strcat> kdave: bug.h can't be included in string.h
[21:00:06] <strcat> and it needs something for early boot, before it's available
[21:00:22] <strcat> you can see I need to define this symbol for arch/x86/boot/compressed/misc.c for example
[21:00:26] <strcat> and there will be some other cases
[21:02:35] <strcat> kees: yeah strlcpy needs a minor tweak, it's checking for memcpy overflow but not the \0 it adds
[21:02:39] <strcat> so need to roll a custom check there
[21:05:50] <strcat> kdave: I'd like to do an oops instead of a panic there, essentially, but I want it to remain noreturn
[21:11:05] *** Joins: kerframil (~kerframil@gentoo/user/kerframil)
[21:24:08] <strcat> kees: sadly I think it probably makes sense to move the strlen/strnlen code into a macro to reuse it without getting that extra function layer
[21:24:10] <strcat> ;\
[21:24:12] <strcat> I'll deal with that later
[21:26:06] <strcat> I'll see in a sec
[21:30:28] *** Quits: strcat (~strcat@archlinux/trusteduser/thestinger) (Quit: brb)
[21:33:28] *** Joins: ch40s[m] (etherdisro@gateway/shell/matrix.org/x-fcikzgostqjpcmqq)
[21:35:38] *** Joins: strcat (~strcat@archlinux/trusteduser/thestinger)
[21:35:39] *** ChanServ sets mode: +o strcat
[21:37:24] <kdave> strcat: the noreturn for fortify_panic is required just to generate sane code?
[21:37:39] <strcat> kdave: it reduces the code size it adds
[21:38:08] <strcat> kdave: it'd be better if it could call BUG directly
[21:38:18] <strcat> although then the error is kinda incomprehensible
[21:38:31] <kdave> what I'm thinking: there are some sysclt knobs panic_on_XXX so would you want panic_on_fortify to be such sysctl? then there would have to be a switch and the whole function couldn't be noreturn
[21:38:44] <kdave> if the panic is not the only option
[21:38:54] <strcat> kdave: well, it really needs to end the thread
[21:38:57] <strcat> it shouldn't continue
[21:39:04] <kdave> hmm
[21:39:34] <strcat> for example, if it decided to continue, should it do the overflow, or refuse to do it and keep going, maybe truncating the copy
[21:39:41] <strcat> I think it needs to just stop
[21:39:46] <strcat> but it doesn't need to panic
[21:39:56] <strcat> if it can guarantee ending the thread
[21:40:01] <strcat> and I do think __noreturn is important there
[21:40:24] <strcat> in fact, I think what I'm doing now probably generates too much code, but I don't see a way to keep it usable while doing less
[21:40:46] <strcat> but I want to start simple, so not bloated, but not micro-optimized yet
[21:41:02] <strcat> if I started doing micro-optimization prematurely I'd make it harder to land
[21:41:41] <strcat> step 1 == landing basics, with __noreturn, and having people add fortify_panic impls for arch-specific areas needing it
[21:42:10] <kdave> yeah it looks to me pretty good in this form, I havent' seen the asm though
[21:42:47] <strcat> kdave: it inserts code to maybe 30% of memcpy, strlen, etc. locations and it's just 1 branch (for the mem* stuff at least) but there are a lot, so it matters
[21:43:22] <strcat> kdave: I have __func__ there b/c otherwise it's harder to tell what's going on
[21:43:35] <strcat> although that is more bloat ;p
[21:43:57] <kdave> sure, but when fortify fires you want to know where :)
[21:44:42] <kdave> maybe some section annotations or compiler hints to help to split hot/cold parts
[21:44:51] <strcat> kdave: well I has __cold on fortify_panic
[21:44:52] <kdave> I slightly doubt that mere likely/unlikely will help much
[21:45:02] <strcat> kdave: __cold makes any branch calling the function unlikely already
[21:46:27] <strcat> and it's supposed to put all the cold functions together, I guess below everything else, although I dunno where modules end up in relation to cold core code
[21:47:11] <strcat> kdave: I realized I can improve strncat/strlcpy code size though
[21:47:16] <strcat> w/e
[21:47:28] <strcat> stupid __func__ ;p
[21:49:15] *** Quits: strcat (~strcat@archlinux/trusteduser/thestinger) (Quit: brb)
[21:50:15] <kdave> can __builtin_object_size checks be lifted from the function? if thery're supposed to be compile-time only, they should not generate any code if the arg lengths are known
[21:50:44] *** Joins: strcat (~strcat@archlinux/trusteduser/thestinger)
[21:50:44] *** ChanServ sets mode: +o strcat
[21:51:06] <strcat> kees: https://github.com/thestinger/linux-hardened/commit/ae3e1753dc61a50a65a57be28e8ffe2c9f62c0f9.patch new ver, has stricter strlcpy impl
[21:51:31] <strcat> it was allowing up to a 1 byte write overflow before since it only checked memcpy then set the \0
[21:51:52] <strcat> so it was better than nothing but not actually fully checking it
[21:54:35] <strcat> making some minor changes to improve code size / errors a bit though
[21:54:58] <strcat> hm
[21:55:13] <strcat> actually w/e, it's good for now
[21:55:36] <strcat> iirc using a 'static inline' from this weird gnu extern inline will be bad
[21:55:43] <strcat> and I don't want a macro mess yet
[22:16:12] <kdave> strcat: have you seen this https://pastebin.com/raw/bzd40BVv ? could be related to issue 27
[22:17:24] <strcat> kdave: try with https://github.com/thestinger/linux-hardened/releases/tag/4.11.1.b
[22:17:33] <strcat> kdave: I don't have the fixes for fortify stuff in the standalone patch
[22:17:47] <strcat> kdave: kees and I upstreamed some already, so I have some cherry-picked from upstream and some temporary workarounds
[22:18:17] <strcat> kdave: https://github.com/thestinger/linux-hardened/commit/0379fd08610fec0cff30fb515c70a2cb521492bd is prob that
[22:18:21] *** Joins: decoy_N3g3v (~decoy_N3g@KD118157015215.ppp-bb.dion.ne.jp)
[22:18:55] <strcat> I think kees got it fixed properly upstream 'somewhere' but I'll wait for the actual fixes since they are spread out in different trees
[22:19:09] <kdave> yes that's the memcpy call
[22:19:46] <strcat> kdave: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/fortify&id=95d589f21b3aef757f0eb3d0224b78648a4b22d2 is the proper fix
[22:20:26] <strcat> most were abuse of memcpy on string constants using dest buffer size, so read overflows copying some junk from rodata
[22:23:31] *** Quits: umoot (d598a145@gateway/web/freenode/ip.213.152.161.69) ()
[22:26:31] <kdave> I see, thanks
[22:37:46] *** Quits: decoy_N3g3v (~decoy_N3g@KD118157015215.ppp-bb.dion.ne.jp) (Read error: Connection reset by peer)
[22:41:42] *** Joins: decoy_N3g3v (~decoy_N3g@89.160.93.123)
[22:46:40] *** Quits: decoy_N3g3v (~decoy_N3g@89.160.93.123) (Ping timeout: 240 seconds)
[22:49:35] *** Quits: dave0x6d (uid190567@gateway/web/irccloud.com/x-ryqhvjoqdgrjvdfb) (Quit: Connection closed for inactivity)
[22:55:21] *** Joins: dave0x6d (uid190567@gateway/web/irccloud.com/x-cfcrraceppddejut)
[22:56:15] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[23:08:14] <strcat> kdave: I expect that bug that's reported is a runtime strlcpy error
[23:08:25] <strcat> b/c it's the only one I added since the last ver they say worked
[23:08:33] <strcat> and I doubt other changes could have done it...
[23:08:38] * strcat shrugs
[23:19:04] *** Joins: umoot (d598a268@gateway/web/freenode/ip.213.152.162.104)
[23:21:04] *** Joins: b0untea (~b0untea@78.192.96.126)
[23:23:22] <strcat> kdave: meh they say it happens without CONFIG_FORTIFY_SOURCE but I can't really see how that's possible
[23:29:38] <strcat> they say 4.11.f worked, 4.11.1.a doesn't
[23:29:42] <kdave> that's strange
[23:29:44] <strcat> so there are only a couple changes
[23:30:06] <strcat> fortify changes (which are ruled out, if I trust that they didn't make a mistake)
[23:30:15] <strcat> upstream 4.11.1 changes
[23:30:23] <strcat> and a couple __ro_after_init
[23:32:54] <strcat> __supported_pte_mask and kernel_set_to_readonly __ro_after_init are the only other changes other than fortify between those
[23:33:06] <strcat> oh and the extra latent entropy thing
[23:33:20] <strcat> but that's not enabled by default
[23:39:51] *** Quits: blueness (~blueness@gentoo/developer/blueness) (Quit: blueness)
[23:42:31] <strcat> this was meant to be collaboratively but it seems I'm doing more than I expected :\
[23:42:35] <strcat> collaborative*
[23:43:55] <kdave> sorry I can't help, I need to refresh the code and some parts I don't really understand
[23:45:10] <strcat> it'd help if someone could replicate that hibernate bug
[23:45:27] <strcat> I wonder if they're using xen
[23:46:06] *** Joins: blueness (~blueness@gentoo/developer/blueness)
[23:46:29] <kdave> I have a spare notebook here, will try to reproduce it
[23:47:12] <strcat> kdave: yeah lots of the code is really complicated, that's why I want to extract it bit by bit
[23:47:22] <umoot> strcat: hi, I'm reporter of this bug
[23:47:39] <strcat> umoot: are you using a VM or real hw?
[23:47:49] <umoot> strcat: real hp laptop
[23:47:57] <strcat> ok so not this xen thing I see
[23:48:29] <kdave> umoot: can you please paste .config?
[23:48:39] <umoot> strcat: i'm compiling 4.11.1 with 4.11.f hardened now
[23:48:48] <strcat> umoot: k if that work it narrows this down a lot
[23:49:21] <strcat> umoot: I can make a patch undoing half of the 4.11.a changes to try, then maybe another, and then we should know which it is, at least
[23:50:01] <strcat> there are 4 changes: extra latent entropy, __ro_after_init for __supported_pte_mask, __ro_after_init for kernel_set_to_readonly (along with moving where it's set) and the fortify changes
[23:50:09] <strcat> so the fortify changes should be ruled out since you tried with it disabled
[23:51:11] <strcat> I don't think suspend works on my desktop with vanilla so...
[23:51:23] <strcat> I could try on my laptop
[23:51:39] <umoot> strcat: here's config https://ghostbin.com/paste/pa69p
[23:51:44] <strcat> kdave:
[23:52:24] <strcat> ah it's the arch linux one
[23:52:32] <umoot> strcat: it's copied from arch, I disabled ipv6 an unused modules


以上诗句，不要放在`ul`中，放在 `p` 中， `p` 表示段落。

```
<p>
岱宗夫如何，齐鲁青未了。<br/>
造化钟神秀，阴阳割昏晓。<br/>
荡胸生层云，决眦入归鸟。<br/>
会当凌绝顶，一览众山小。<br/>
</p>
```
这样简单处理即可。


- Seems like some changes have been made to connections.
- Changes made to context menus on system messages -> this bug has been fixed https://trello.com/c/mDJlBwfp


![](https://github.trello.services/images/mini-trello-icon.png) [Refactoring v1.0](https://trello.com/c/4NLH5SKz/20-refactoring-v1-0)


@NicholasAnaya some of these styles already exist as css selectors in global-styles.scss
ex: `.centered-text { text-align: center; }`
adding that class to the html will save us a bit of css markup! let's chat quick about that tomorrow


文章信息区，不要放在`h6`中。参考
```html
                        <div class="text-small text-gray">
                            <span>杜甫</span>
                            <time class="ml-2">2017年1月1日 10:00</time>
                            <a  class="ml-2" href="blog/view.html">查看更多</a>
                            <a  class="ml-2" href="blog/edit.html">编辑</a>
                        </div>
```


Otherwise you get `java.lang.UnsupportedClassVersionError: com/android/build/gradle/AppPlugin : Unsupported major.minor version 52.0` when trying to build the project.


New regex can now also detect community IDs that do no start with nm or sm.


分页栏应该跟文章区属于同一个层级，要放在一起。


叹号放在文字后面


I think this is a behavioral change. should use a pattern instead.


`btn-default btn-primary` 两个只能选用一个。


Impressive find VoyagerOne. Congratulations!


@NicholasAnaya the twelve column container is a bit redundant, we should be able to remove that without creating any issues. also, please keep the formatting as as clean as possible!


this one is critical


After years I finally had the patience to fix this bug


Before:

![image](https://cloud.githubusercontent.com/assets/1924134/26082973/dcf2f1c6-39a0-11e7-9a3d-529242d6a4f2.png)

After:

![image](https://cloud.githubusercontent.com/assets/1924134/26082975/e54483f8-39a0-11e7-88bb-1061ca6a8487.png)


`leichte` Graphen


should this be a tuple and not an array?


A typo caused the problem. The original code used the following in UncheckedSetKey, which is where ciphers are keyed:

    m_tweak[2] = m_tweak[0] + m_tweak[1];

The correct code is:

    m_tweak[2] = m_tweak[0] ^ m_tweak[1];


Hi, Nick.  Congrats, you have our first external merge to master.  I think that merits some swag.  Can you send me a T-shirt size and shipping address?


Arquivos do projeto


3 [0,5] patches in one day, wow.
Although you probably should try other values in case some of them bringing even more elo.


Congrats!


Comment on 712354b


I think you forgot to push `pkgconfig` function


okay, but what's the plan on prioritising nearby chunks for chunk updates?

Chunk sorting wasn't that expensive when I tested: it's only done every 2.5 seconds

You can still std::sort on deques iirc


working on it


Yes, you _are_ on fire. Congrats again Stephane!


for #36 and #37


@zkdtc, can you please confirm that you are receiving notices from GitHub?  You made this commit after I asked you to not commit directly to master.


aight o7


Congrats!!


Congrats again!


PCM-NRGSim-NREL-SBV (Myoldmopar) - x86_64-Linux-Ubuntu-14.04-gcc-4.8-UnitTestsCoverage-Debug: OK (1294 of 1294 tests passed, 1 test warnings)

![Build Badge](http://img.shields.io/badge/build%20status-passing-green.png) ![Test Badge](http://img.shields.io/badge/tests%20passed-100.0%25-green.png) ![Coverage Badge](http://img.shields.io/badge/coverage%20status-37.63%25-green.png)


aren't you missing the throttle?


New-Feature---Increase-speeds-in-multispeed-object (rraustad) - i386-Windows-7-VisualStudio-14: OK (2490 of 2496 tests passed, 0 test warnings)

Failures:

EnergyPlusFixture Test Summary
 * Passed: 462
 * Failed: 5

integration Test Summary
 * Passed: 600
 * Failed: 1

![Build Badge](http://img.shields.io/badge/build%20status-passing-green.png) ![Test Badge](http://img.shields.io/badge/tests%20passed-99.76%25-yellow.png)


Perhaps it would be worth tuning this value(?)


修改 for 和 id属性值


makes sense :) missed that circleCount was actually a number. 👍


Um, you have to account for 0, so yeah this is wrong.

It should be 2^30 - 1 for 1GB aka 1,073,741,824 bytes


In the commit message, I meant to to say **Gitiles** server, not Gerrit server.


~~\pause~~


Nice!


![](https://github.trello.services/images/mini-trello-icon.png) [settings en archivo](https://trello.com/c/KQ1jwTt7/3-settings-en-archivo)


That makes sense, I have completely overlooked this "rule". I also get the point with easier error stacking tracing and more explicitly distinguish "regular" and anonymous functions :)

Think I will implement this "rule" right away 👍


Created multidev environment [badcamp-2017#ci-98](https://dashboard.pantheon.io/sites/8d658997-7a61-4db8-9be8-0f16b8b62022#ci-98).

[![Visit Site](https://raw.githubusercontent.com/pantheon-systems/ci-drops-8/0.1.0/data/img/visit-site-36.png)](https://ci-98-badcamp-2017.pantheonsite.io/)


Nein, „licht“ ist hier Gegensatz zu „dicht“ (vgl. „duennbesetzt“ und “sparse”) und meint einen Graphen mit (vergleichsweise) wenigen Kanten, also einen Graphen, in dessen Adjazenzmatrix ueberwiegend Nullen stehen.


Sounds good!


@depaolif this width is competing w/ the width of .shell, which is making .navbar too wide


❤
This port looks amazing, have you made any further progress with it?
Do you want to open a PR? Even just for others to find and continue your work, if you don't want to.


```
diff --git a/R/create-docs.sh b/R/create-docs.sh
index 310dbc5fb5..c111263d4f 100755
--- a/R/create-docs.sh
+++ b/R/create-docs.sh
@@ -49,7 +49,7 @@ pushd "$FWDIR" > /dev/null
 mkdir -p pkg/html
 pushd pkg/html

-"$R_SCRIPT_PATH/Rscript" -e 'libDir <- "../../lib"; library(SparkR, lib.loc=libDir); library(knitr); knit_rd("SparkR", links = tools::findHTMLlinks(paste(libDir, "SparkR", sep="/")))'
+"$R_SCRIPT_PATH/Rscript" -e 'libDir <- "../../lib"; library(SparkR, lib.loc=libDir); sparkR.session(); library(knitr); knit_rd("SparkR", links = tools::findHTMLlinks(paste(libDir, "SparkR", sep="/")))'

 popd
```


to get this working smoother, do `.container-name > .shell > .columns`


vnbvn


I would say to leave it as-is for now. Right now the system is a little bit messy because I tried to give as many customization points (overridable functions) as possible, but I might have gone a little bit overboard; there's some redundancy as it relates to the rules regarding vehicle spawning. If I went back and ever tried to add another spawn point type that allowed vehicles, I get the feeling I would be reinstating this `CanSpawnVehicle` function and reorganizing things a little bit.

TL;DR: Leave it for now.


Fixed in c43f62cb10b2814569c6b9ecc287ae92090890c1.


let's keep this formatted nicely, will be easier to read!


Hi Ben,
    Oh, sorry about that… I just saw your reminders. Sorry about the confusion and inconvenience… I will revise it.
    Best~
                                Kai

> 在 2017年5月15日，下午4:16，Benjamin Alan Weaver <notifications@github.com> 写道：
>
> @zkdtc <https://github.com/zkdtc>, can you please confirm that you are receiving notices from GitHub? You made this commit after I asked you to not commit directly to master.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/desihub/desidatamodel/commit/1446c2f3230f2f1f8be3dc974117238faa2b5e5e#commitcomment-22151293>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZK4vWF9SsL9IR0s6N9W_ZptHEWqEh-fks5r6NzfgaJpZM4Nbz0H>.
>


@Netuddki
Can you update "bnet.hr.channels.xml" file.
Some channels missing?


突然一下子干净多了，赞


adding `box-sizing: content-box;` might help here


If we're to have the atomspace hold most of the configuration (which I agree is good), we probably want to move some of that code https://github.com/opencog/atomspace/blob/master/opencog/rule-engine/UREConfigReader.h and https://github.com/opencog/atomspace/blob/master/opencog/scm/opencog/rule-engine/rule-engine-utils.scm#L110 in its own place.


Very nice. Assuming it is a better alternative than putting tape on the controller to toggle slow driving for younger participant demos?


closed firewall port http on port 80
opened firewall port https on port 443
change mlexperience.conf in /etc/apache2/sites-available to add virtual server :443 with the
SSL key and SSL cert stated in the conf file.
fixed a bug in log.txt -> was pointing to log.js

verified app running in production


Tem certeza? Lua sabe os tipos dos operandos em tempo de compilação?


Isso não é um nome, mas vou aceitar pela explicação...


That's what I was thinking. I'm trying to make it easier to control in general - I moved everything to one gamepad.


Created multidev environment [badcamp-2017#ci-99](https://dashboard.pantheon.io/sites/8d658997-7a61-4db8-9be8-0f16b8b62022#ci-99).

[![Visit Site](https://raw.githubusercontent.com/pantheon-systems/ci-drops-8/0.1.0/data/img/visit-site-36.png)](https://ci-99-badcamp-2017.pantheonsite.io/)


Congrats!


Bluemix [toolchain](https://console.bluemix.net/devops/toolchains/9eb30fe7-7b78-403f-aa51-1b4d039d678b "DTVAUTO"): [Delivery Pipeline](https://console.bluemix.net/devops/pipelines/15ed235f-d9f5-4c0a-8e9b-c1e53dcdf5bb "DTVAUTO") deployed [DTVAUTO](https://github.com/gusan3/DTVAUTO/releases/tag/deploy-ibm-yp-us-south-gusan-test-20170515-234254 "deploy-ibm-yp-us-south-gusan-test-20170515-234254") to [test](https://console.ng.bluemix.net/apps/0a7782ee-feac-4208-8a85-29d0e72d8610 "ibm:yp:us-south:gusan:test"), including this commit


First off, I want to say thanks for all the work you put into this. I've been looking for a program like this and happened across it.

This IMF feature is a big one I'm excited about, it's helped me immensely with a current project of mine.

Anyway, I've compiled the source, and the commander keen imfs work great, but I can't seem to get the Duke Nukem II ones working. I assume you know this already, but I was just curious if a fix in the works.


This is a behavioural change. But that aside, why not actually remove the runtime tagmap lookup and use a `required_ioport_array` like we're trying to encourage?


Had done this at https://github.com/libretro/libretro-super/pull/459 , but you got it! :+1:


Excellent!  A very good day for Stockfish!


@jtaubensee do you want to log here anything?


Created multidev environment [badcamp-2017#pr-85-mail](https://dashboard.pantheon.io/sites/8d658997-7a61-4db8-9be8-0f16b8b62022#pr-85-mail).

[![Visit Site](https://raw.githubusercontent.com/pantheon-systems/ci-drops-8/0.1.0/data/img/visit-site-36.png)](https://pr-85-mail-badcamp-2017.pantheonsite.io/)


Changed Calibration to wait for user input for every calibration point, hardcode option to bypass the waiting, and checked probe and gantry functions work with the code as is


nice


Changed Map Update Timer~ Map Has Refresh Issue Need To Debug~


I will make another page. this could be the "code breaking" page


Idea here is that models can specify how their deletion process works, which gets tricky as we move farther away from relational data.

This would also  contain some kind of BulkDeletionTask that we'd specify for certain models like we do within ``tasks/deletion.py`` right now


If you can be bothered, I'd certainly be grateful!


Created multidev environment [badcamp-2017#pr-80-behat](https://dashboard.pantheon.io/sites/8d658997-7a61-4db8-9be8-0f16b8b62022#pr-80-behat).

[![Visit Site](https://raw.githubusercontent.com/pantheon-systems/ci-drops-8/0.1.0/data/img/visit-site-36.png)](https://pr-80-behat-badcamp-2017.pantheonsite.io/)


@Phoenix616 Can you open the issue tracker on the repo so future issues can be reported there, assuming this is now the 'official' chestshops fork?

Players who formerly have a chest shop but then change their name, if they create a new shop after the fact, it redirects the sign to their old name. Is there any way to update old name signs / newly create shops under that player's UUID to use their new name?


Oh okay, makes sense. It's the same but the keys are typically written as "control" and "option" instead of "CTRL" and "ALT," but people can probably figure it out


Thanks for changing this. Now that we're using standard variable names, we should avoid passing them to the boto3 client altogether. In general, each of the cloud API clients has a config hierarchy where it can ingest the credentials from a number of sources, and we should rely on that automated implicit behavior. So I'm going to refactor this code so it passes these keys out-of-band.


Created multidev environment [badcamp-2017#ci-102](https://dashboard.pantheon.io/sites/8d658997-7a61-4db8-9be8-0f16b8b62022#ci-102).

[![Visit Site](https://raw.githubusercontent.com/pantheon-systems/ci-drops-8/0.1.0/data/img/visit-site-36.png)](https://ci-102-badcamp-2017.pantheonsite.io/)


Well on Mac they have a `preferences` option under the `Atom` menu, not the file menu, so I was just referring to the `Settings` screen in general


I would write `let x: &Option<i32> = &Some(3);` rather than these two lines and the comment on line 130


typo - dereferenced -> dereference


s/variables/values (or expressions)


Good thinking.


Not long, it's just I can't be bothed.
I can do it on weekdays, when I'm st college. (Else, I would have done it on laptop if it was fixed)


I would s/we/the compiler/ s/change/treat/ s/to/as/


should be `i += 3;`


Could also be `todo.unloadRecord()`


1. `i`
2. `0..5`, but this is `Range` type value but we haven't support it yet.
And in this case `for i in 0..5` is not a condition actually.


Could you give an example which requires multiple dereferences please?


I think you can open an issue and list all possible forms of `for statement`, then we can decide how to parse it.


Clarification: what if an un-annotated variable is nested inside a `ref` pattern? Does `ref` stop traversing for binding mode, or set the current mode?


head dfu


I don't see the point to this


And you don't do it here, why


@OKaluza, these explicit casts appear to be necessary with clang, otherwise I get some error about ambiguous operator overloads.  Perhaps they can be cast to 'unsigned' to avoid warnings?


@OKaluza this one too.


Yeah, that's a regression, will fix. I usually rely on jenkins to find these clang errors if I miss them but it's down.


@OR13 cache me outside


I don't even know that meme, but colin says it all the time


Window 命令行需要用双引号


Mongoose schema 对象可以直接操作数据库。


Do you care about parenthesization here?  (Not that there's much we can do to fix it, probably, since the associativity of `*` is hardcoded in the std-lib...)


I guess we could add parentheses around everything, if you really care...


Related to: backdrop/backdrop-issues#2660


这样的测试程序只能在有真实数据存到数据库之后该怎么办，总不能一运行测试就清空数据库吧。


Amending #3 for reference


a


Related to: backdrop/backdrop-issues#2093


Explain this line :P


单例


hi. i want to contact you for something. can you please give me an email address? thanks


This is also generally safe to use, I haven't seen any issues since the launch of nougat using O3 on clang compiled components


![](https://github.trello.services/images/mini-trello-icon.png) [Roll](https://trello.com/c/l4aF8gMS/21-roll)


![](https://github.trello.services/images/mini-trello-icon.png) [User database model](https://trello.com/c/f1Gd2KF6/5-user-database-model)


![](https://github.trello.services/images/mini-trello-icon.png) [PostgreSQL database connection](https://trello.com/c/4uuUfv5n/30-postgresql-database-connection)


Not sure why I just now got this notification on GitHub, but it was my pleasure sending you a little help!


obrigado


this would need to be listed in REQUIRE


encode -> decode


的拒绝到付到年底


I don't think we do


Amending #3 and #6 for future reference


Please remove this variable


`s/Abour/About/`


Se nesse caso, você tem que executar uma coisa diferente apenas quando ` i === 1`, então pq vc não fez seu `if` fora do `for`?

por exemplo:
```
for (i = 99; i > 1; i -= 1) {
// (code here...)
}

// código responsável pela a lógica de i === 1, porém sem if porque você sabe que no fim do for o i vai ser 1 garantidamente
console.log(...)
```


네이밍 센스가 개 똥같군요


Thank you very much for these fixes!


Executing the daily benchmark build, I will reply here when finished:

@nanosoldier `runbenchmarks(ALL, isdaily = true)`


typo? dispensable, not dispendable?


@jsrikrishna Can you review this ?


标记一下预想输出和实际输出啊，没看懂 :rofl:


vbbhbhb


bangla recipe à¦¬à¦¾à¦‚à¦²à¦¾ à¦°à§‡à¦¸à¦¿à¦ªà¦¿ new


Right. Removed in https://github.com/phpmyadmin/error-reporting-server/commit/858b2f1ea6ffaed2b682832a34527cb3f74fdbf2.

Thanks for pointing out.


![](https://github.trello.services/images/mini-trello-icon.png) [Add Shape Creation and Destruction](https://trello.com/c/qhyRrL5i/12-add-shape-creation-and-destruction)


file作成


file削除


Hi Yice,

You are correct, the first three gains are the PID gains.  The next
numbers are an outer loop closed around the wheel encoders. The outer
loop for forward/back motion is a PD loop, and for rotation is a
proportional loop.

The details on the encoder I used can be found at:
https://www.pololu.com/product/2823

You can adjust the math based on your wheel diameter, encoder counts per
revolution, and gear ration.

The behavior you describe with the gyro response being delayed sounds
suspicious.  Check the signs on your accelerometer and gyro axes, and
the data going into the Kalman filter.  Output response should seem
instantaneous.  If the Kalman filter output looks delayed, it could be
that the rate input has a sign flip.   You might create a small program
just to process the gyro data through the filter and look at the
response over the serial monitor. That's what I needed to do.

Finally, regarding gain tuning, here is the approach I took. Start with
the D gain.  Slowly raise to max value where you can balance between
your hands without oscillating.  Then raise the other two, lowering the
D gain as needed to prevent oscillation. Plan on spending a few hours
tuning using trial and error to get the best response while not falling
when using the joystick.

Larry

On 5/14/2017 12:40 PM, kordisss wrote:
>
> Hi,
> I want to thank you for your great project firstly.
> I made your project all same and I use two different parts. They are;
> L298H motor driver and http://s.aliexpress.com/I7jMBviQ encoder motors.
> I want to ask you some question;
>
> #define K_p 15.0f
> #define K_i 100.0f
> #define K_d 0.15f
> #define wheelPosGain 0.0015f
> #define wheelRateGain 0.003f
> #define Kp_Rotation 0.1f
> #define MaxAngleOffset 5.5f
>
> Kp-ki-kd are our pids is it? What is the others?
>
> ------------------------------------------------------------------------
>
> #define DEG_PER_COUNT 0.75f // 480 Counts per Revolution
> #define VOLT_PER_COUNT 0.01465f // 5 V * (30 kOhm)/(10 kOhm) / 1024
>
> Is there any encoder spec there?
> My encoder is 390 line. Is there any changes needed or not?
>
> ------------------------------------------------------------------------
>
> // Calculate Wheel Position & Speed at 10 Hz
> if (millis() - WheelSpeedTimer > 100) {
> wheelPosition = 0.5f * (LeftEncoderTicks + RightEncoderTicks) *
> DEG_PER_COUNT;
> wheelVelocity = 10.0f * (wheelPosition - lastWheelPosition);
> rotationAngle = 0.5f * (LeftEncoderTicks - RightEncoderTicks) *
> DEG_PER_COUNT * 0.486f; // Rotation angle in deg. Note: wheel diam =
> 104 mm
>
> I changed wheel diameter and distance Between wheel. Is it need to be
> change?
>
> ------------------------------------------------------------------------
>
> I started to adjust pids and p is 5.0
> i is0.0 d is 0.0 for the first standup.
>
> Everything looks working good but there was a problem there. My gyro
> starts action about 15-20 degree later after robot tilt. How can I
> adjust it ?
>
> Best regards
> Yuce.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/elkayem/ZippyTheBalancingRobot/commit/7040419d2bca375367ea56d64644a4a9af81df40#commitcomment-22134025>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AOKwFwIU-DJZ_0a9Hk_4HAgbXfpkmrJoks5r51jLgaJpZM4Naewb>.
>


test


file revert


在单词初记界面，点z / 键。。。 下面的导航的 反复记忆 应该有个badge的，数字在上涨


tente usar variáveis com string, ou invés de string inline nesse caso, porque a mesma string se repete em dois lugares diferentes:
```js
var lyrics = {
    first: 'of beer on the wall,',
    second: 'of beer.',
    third: 'Take one down and pass it around,',
    fourth: 'of beer on the wall.',
    fifth: 'No more bottle of beer on the wall, no more bottles of beer',
    final: 'Go to the store and buy some more, 99 bottles of beer on the wall.'
};

//e uma funcao para o seu plural
function pluralBottle(i) {
    return (i > 1) ? 'bottles' : 'bottle';
}

//entao use assim:
console.log([
    [i, pluralBottle(i), lyrics.first].join(' '),
    [i, pluralBottle(i), lyrics.second].join(' '),
    [lyrics.third, i - 1, pluralBottle(i - 1), lyrics.fourth].join(' ')
].join('\n'));
```

só usar uma logica similar pro último caso. (note: `[].join()` é uma funçao que concatena todos os elementos do array em uma string. O parametro opcional do `join` é uma string que vai ser adicionada entre os elementos do array. brinque com essa funcao no terminal)


Так как имя есть у всех типов объектов, то стоило определить конструктор с именем в QMFObject


`# Pong project by Suyash Gautam

import random
import simplegui

# Initialize variables
br = 12
bv = [random.randrange(2,4), -random.randrange(1,3)]
h=600
w=1000
bp = [w/2,h/2]
pw = 15
ph = 120
hpw = pw/2
hph = ph/2
p1pos = float(h/2)
p2pos = float(h/2)
pad1v = float(0)
pad2v = float(0)
score1 = 0
score2 = 0

def spawn_ball(right):
    global bv, bp
    bp = [w/2,h/2]

    if right:
        bv = [random.randrange(3,5), -random.randrange(2,4)]
    else:
        bv = [-random.randrange(3,5), -random.randrange(2,4)]

def new_game():
    global p1pos, p2pos, pad1v, pad2v
    bp = [w/2, h/2]
    global score1, score2
    score1 = 0
    score2 = 0
    p1pos = float(h/2)
    p2pos = float(h/2)
    pad1v = 0.0
    pad2v = 0.0
    spawn_ball(True) # will spawn to the right

def draw(canvas):
    global bv, bp, p1pos, p2pos, score1, score2
    # Update ball position
    bp[0] = bp[0] + bv[0]
    bp[1] = bp[1] + bv[1]
    canvas.draw_circle(bp, br, 10, "red", "White")
    # write collision rules

    # collide and reflect of the bottom size of the canvas
    if bp[1] <= br:
        bv[1] *= -1.02
    # collide and reflect from the top side
    if bp[1] >= (h - br):
        bv[1] *= -1.02

    #collision from the left pad
    # if it hits the left gutter
    if bp[0] <= (br + pw):
         # if it hits the pad on the left gutter
        if (p1pos - hph <= bp[1] <= p1pos + hph):
            bv[0] *= -1.1
            bv[1] *= 1.1
        else:
            score2 += 1
            spawn_ball(True)
    # if it hits the right pad
    elif bp[0] >= (w - pw - br) :
            if (p2pos - hph <= bp[1] <= p2pos + hph):
                bv[0] *= -1.1
                bv[1] *= 1.1
            else:
                score1 += 1
                spawn_ball(False)
    #Drawing Pad 1 and 2
    canvas.draw_polygon([(0, p1pos - hph), (pw, p1pos - hph), (pw, p1pos + hph), (0, p1pos + hph)], 1, "White", "White")
    canvas.draw_polygon([(w - pw, p2pos - hph), (w, p2pos - hph), (w, p2pos + hph), (w - pw, p2pos + hph)], 1, "White", "White")

    #Keeping the pads on the screen
    if p1pos + pad1v >= hph and p1pos + pad1v <= (h-hph):
        p1pos = p1pos + pad1v
    if p2pos + pad2v >= hph and p2pos + pad2v <= (h-hph):
        p2pos = p2pos + pad2v
    # drawing gutters
    canvas.draw_line([w / 2, 0],[w / 2, h], 4, "White")	#midline
    canvas.draw_line([pw, 0],[pw, h], 4, "White")	#left gutter
    canvas.draw_line([w - pw, 0],[w - pw, h], 4, "White")	#right gutter
    canvas.draw_text(str(score1), [100, 100], 52, "White")
    canvas.draw_text(str(score2), [900, 100], 52, "White")

# Moving paddle 1
def keydown(key):
    global pad1v, pad2v
    padacc = 8
    if key == simplegui.KEY_MAP["w"]:
        pad1v = pad1v - padacc
    elif key == simplegui.KEY_MAP["s"]:
        pad1v = pad1v + padacc
    elif key == simplegui.KEY_MAP["up"]:
        pad2v = pad2v - padacc
    elif key == simplegui.KEY_MAP["down"]:
        pad2v = pad2v + padacc

# Moving paddle 1
def keyup(key):
    global pad1v, pad2v
    padacc = 5
    if key == simplegui.KEY_MAP["w"]:
        pad1v = 0
    elif key == simplegui.KEY_MAP["s"]:
        pad1v = 0
    elif key == simplegui.KEY_MAP["up"]:
        pad2v = 0
    elif key == simplegui.KEY_MAP["down"]:
        pad2v = 0

frame = simplegui.create_frame("Pong by Suyash", w, h)
frame.set_draw_handler(draw)
frame.set_keydown_handler(keydown)
frame.set_keyup_handler(keyup)
frame.add_button("Restart", new_game)

frame.start()
new_game()

`


Аналогично name, только logger даже в конструктор не надо добавлять


update theme


In above code added by commit

first line should be if( ! $col['datatable_where']), i think you skipped (!) operator.


Specifically, fixes #944


Looks good, thanks! Previously you had suggested using the repl mode in Documenter.jl instead of doctests, so that it automatically places the output. Has this changed?


I love how linux used !!!, with !! (bang bang) to produce git add --all!


Slidify presentation


If we can avoid setting this one, that'd be good (since it disables SNI).  But, if we have to, we have to.


fkugkjjkkjh


Related to: backdrop/backdrop-issues#1700


This is very clever, I didn't know that it was possible! (I thought it will evaluate to `True`)


for more functions, refer to: http://sass-lang.com/documentation/Sass/Script/Functions.html


try:

```ruby
<%= render partial: 'collaborators/collaborator_form', locals: { user: @user_id, wiki: @wiki_id } %>
```

This is necessary because you're rendering a partial from another resource.


If `@user_id` is a collection of user_ids, then this definitely isn't going to work. Because you'll be colling `.build` on an array of ids.


まあ


私のソースよりは役に立ちますよ(´･ω･｀)


"adjustPan" for the Image to not flicker/change its shape on any Text Input


The 1.10.1 branch where this commit has been made lacks src/audio/backend/openal.h and src/audio/backend/openal.cpp.


や


We need to include each and every package that are hooked with native


大概是这里 https://cn.vuejs.org/v2/guide/components.html#字面量语法-vs-动态语法