Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
> I won't fail to defend general anti-nym opinion or guidance d-oh, s/defend/defend against/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
>> grarpamp >> the various good uses for nyms. > cpgh...@cordula.ws > I hope you realize whom you're trying to lecture here! > Joerg Wunsch is a highly appreciated long-time FreeBSD contributor Of course. No one here has any question as to anyone's FreeBSD participation. That would be silly :) I merely contest the suggestion that nyms have little to no utility, that people need moderate their usage alone in public, and that those using them are somehow lessers. I won't fail to defend general anti-nym opinion or guidance, particularly when wafted in this general direction. > Now, back to our regular programming. Yes, about this lack of a self-authenticating repo, etc. [1] It is good to see some discussion forming around it :) [1] Or whatever it may better be called. Put another way... we can't yet say, in the strong cryptographic sense, that anyone has a true copy of the repo. Or that the repo is itself internally tamper free and/or tamper proof. And so on as applied down the production and distribution chain. The repo does face certain risks. And Git appears as if it may be one way to mitigate them. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 11/18/12 01:31, Konstantin Belousov wrote:
On Sat, Nov 17, 2012 at 11:05:40PM -0800, Perry Hutchison wrote:
[trimmed some of the lists]
Chris Rees wrote:
... git doesn't work with our workflow.
I'm sure the workflow itself is documented somewhere, but is
there a good writeup of _how_ git doesn't work with it, e.g. what
capabilit{y,ies} is/are missing? Seems this might be of interest
to the git developers, not because they necessarily want to support
FreeBSD as such, but as an example of a real-world workflow that git
currently does not handle well.
Git would work well with our workflow. It supports the centralized
repository model, which the project employs right now.
The biggest issues, assuming the project indeed decides to move to Git
right now, are the migration costs, both in the term of the technical
efforts needed, and the learning curve for the most population of the
committers.
Relatively minor problem, at least with the current rate of the commits,
would be a commit race, when the shared repo head forwarded due to the
parallel commit. The issue should be somewhat mitigated by the Git
allowance to push a set of changes in one push.
git would be a huge step backward from svn for the central repo in lots
of ways. Besides being (in my experience) extremely fragile and
error-prone and the issues of workflow that have been brought up, the
loss of monotonic revision numbers is a really major problem. Switching
SCMs as a result of a security problem is also an action totally
disproportionate with the issue that should not be made in a panic.
Having more [cryptographic] verifiability in the release process is a
good thing; it is not strictly related to the choice of version control
system.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sun, Nov 18, 2012 at 1:57 AM, Garrett Wollman wrote: >> the various good uses for nyms. > > There are no such uses on the FreeBSD mailing-lists; if you wish for > anyone to pay attention to you, then use a real name. Otherwise, > FOAD. > > -GAWollman It appears you have not reviewed the mailing list archives, otherwise you would have found many such nym holders engaging in good participation. However I do thank you for your opinion, and for your delightful and unwarranted private abuse. A good day to you indeed, Sir. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: clang mangling some static struct names?
On Sun, Nov 18, 2012 at 02:37:11PM +0100, Dimitry Andric wrote:
> On 2012-11-16 23:04, Navdeep Parhar wrote:
> >On 11/16/12 13:49, Roman Divacky wrote:
> >>Yes, it does that. iirc so that you can have things like
> >>
> >>void foo(int cond) {
> >> if (cond) {
> >> static int i = 7;
> >> } else {
> >> static int i = 8;
> >> }
> >>}
> >>
> >>working correctly.
> >
> >It's not appending the .n everywhere. And when it does, I don't see any
> >potential collision that it prevented by doing so. Instead, it looks
> >like the .n symbol corresponds to the nth element in the structure (so
> >this is not name mangling in the true sense). I just don't see the
> >point in doing things this way. It is only making things harder for
> >debuggers.
>
> I don't think the point is making things harder for debuggers, the point
> is optimization. Since static variables and functions can be optimized
> away, or arbitrarily moved around, you cannot count on those symbols
> being there at all.
I'd (maybe) buy your argument if the symbol wasn't there at all. But
it's there, just with a .0 appended to it. It hasn't been moved around
or optimized away. In fact, in the case of scsi_low_statics the
compiler added extra noise to the binary (in the form of multiple
scsi_low_statics.[0-4] symbols that no one except the compiler knows
about).
There doesn't seem to be *any* good reason for adding the .n to the
symbols. What is the optimization being attempted here? I lost the
ability to look up some symbols in kgdb and I'd like to know what I
gained in the process :-)
Regards,
Navdeep
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: clang mangling some static struct names?
On Nov 18, 2012, at 5:37 AM, Dimitry Andric wrote:
> On 2012-11-16 23:04, Navdeep Parhar wrote:
>> On 11/16/12 13:49, Roman Divacky wrote:
>>> Yes, it does that. iirc so that you can have things like
>>>
>>> void foo(int cond) {
>>> if (cond) {
>>> static int i = 7;
>>> } else {
>>> static int i = 8;
>>> }
>>> }
>>>
>>> working correctly.
>>
>> It's not appending the .n everywhere. And when it does, I don't see any
>> potential collision that it prevented by doing so. Instead, it looks
>> like the .n symbol corresponds to the nth element in the structure (so
>> this is not name mangling in the true sense). I just don't see the
>> point in doing things this way. It is only making things harder for
>> debuggers.
>
> I don't think the point is making things harder for debuggers, the point
> is optimization. Since static variables and functions can be optimized
> away, or arbitrarily moved around, you cannot count on those symbols
> being there at all.
Bro, do you even debug?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
on 18/11/2012 16:04 Adrian Chadd said the following: > On 18 November 2012 02:48, Andriy Gapon wrote: > >> What you describe is not a workflow issue, but a local development >> environment(s) setup issue. > > Which is a workflow issue. Well, this is what I understand as workflow: google://git workflow http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html "Local workflow" is up to each developer to set up. > I mean, we could bang heads on semantics for hours on end, Indeed. > or we can > realise that git isn't a magic bullet for FreeBSD development. I haven't heard anyone saying that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
Why not make few such places? This will be harder to compromise simultenously two or more. Regards, Alexander Yerenkow 18.11.2012 16:13 пользователь "Aldis Berjoza" написал: > > 18.11.2012, 16:10, "Alexander Yerenkow" : > > How about each commit will make a "tweet"? I'm sure > > twitter could arrange create-records-only (no edit) acount for such > project > > as FreeBSD is. > > This isn't so hard to make, and it's so social :) > > And you would trust twitter? > > -- > Aldis Berjoza > FreeBSD addict > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 18 November 2012 14:04, Adrian Chadd wrote: > On 18 November 2012 02:48, Andriy Gapon wrote: > >> What you describe is not a workflow issue, but a local development >> environment(s) setup issue. > > Which is a workflow issue. > > I mean, we could bang heads on semantics for hours on end, or we can > realise that git isn't a magic bullet for FreeBSD development. Also... did I mention git is GPL? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 18 November 2012 09:09, Alexander Yerenkow wrote: > Integrity could be provided by storing some kind of commit ( each, and > additionally each 1000nd full) checksums (even for svn) somewhere on > readonly format. Google "Merkle Tree" for a method of verifying a log. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
18.11.2012, 16:10, "Alexander Yerenkow" : > How about each commit will make a "tweet"? I'm sure > twitter could arrange create-records-only (no edit) acount for such project > as FreeBSD is. > This isn't so hard to make, and it's so social :) And you would trust twitter? -- Aldis Berjoza FreeBSD addict ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
Integrity could be provided by storing some kind of commit ( each, and additionally each 1000nd full) checksums (even for svn) somewhere on readonly format. How about each commit will make a "tweet"? I'm sure twitter could arrange create-records-only (no edit) acount for such project as FreeBSD is. This isn't so hard to make, and it's so social :) Regards, Alexander Yerenkow ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 18 November 2012 02:48, Andriy Gapon wrote: > What you describe is not a workflow issue, but a local development > environment(s) setup issue. Which is a workflow issue. I mean, we could bang heads on semantics for hours on end, or we can realise that git isn't a magic bullet for FreeBSD development. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: clang mangling some static struct names?
On 2012-11-16 23:04, Navdeep Parhar wrote:
On 11/16/12 13:49, Roman Divacky wrote:
Yes, it does that. iirc so that you can have things like
void foo(int cond) {
if (cond) {
static int i = 7;
} else {
static int i = 8;
}
}
working correctly.
It's not appending the .n everywhere. And when it does, I don't see any
potential collision that it prevented by doing so. Instead, it looks
like the .n symbol corresponds to the nth element in the structure (so
this is not name mangling in the true sense). I just don't see the
point in doing things this way. It is only making things harder for
debuggers.
I don't think the point is making things harder for debuggers, the point
is optimization. Since static variables and functions can be optimized
away, or arbitrarily moved around, you cannot count on those symbols
being there at all.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: clang mangling some static struct names?
On 16 Nov 2012, at 14:04, Navdeep Parhar wrote:
> On 11/16/12 13:49, Roman Divacky wrote:
>> Yes, it does that. iirc so that you can have things like
>>
>> void foo(int cond) {
>> if (cond) {
>>static int i = 7;
>> } else {
>>static int i = 8;
>> }
>> }
>>
>> working correctly.
>
> It's not appending the .n everywhere. And when it does, I don't see any
> potential collision that it prevented by doing so. Instead, it looks
> like the .n symbol corresponds to the nth element in the structure (so
> this is not name mangling in the true sense). I just don't see the
> point in doing things this way. It is only making things harder for
> debuggers.
It's likely that FreeBSD's gdb has to grow support for this new symbol format.
Have you tried using the newest gdb available from ports?
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
on 18/11/2012 10:15 Adrian Chadd said the following: > On 17 November 2012 23:31, Konstantin Belousov wrote: > >> Git would work well with our workflow. It supports the centralized >> repository model, which the project employs right now. > > It may work with your workflow, but it doesn't work with mine. :-) > > Right now the source tree isn't very good at building drivers from a > full HEAD checkout on a -9 or -8 running system. > > The include paths end up pulling from the local sys/net directory, for > example, rather than falling through to the specified kernel build and > kernel source path. > > So at least for me, working almost exclusively in driver/stack land, I > can do sparse check out of only the bits that I'm working on. It lets > me get work done without having to run an up to date -HEAD (and keep > said install up to date.) I also do development on little old netbooks > with SSDs that would make it prohibitive to checkout multiple git > trees. No, using git on a USB/CF/etc card doesn't work very well > either I'm afraid. > > I'm sure there are other use cases. What you describe is not a workflow issue, but a local development environment(s) setup issue. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
Hello, Adrian. You wrote 18 ноября 2012 г., 8:55:54: AC> There's a git repository. It's public. You can look at what goes into AC> the FreeBSD git clone to get your assurance that things aren't being AC> snuck in. People are using it, right now. But commits in this repo aren't signed by developers../ -- // Black Lion AKA Lev Serebryakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 17 Nov 2012, at 23:05, Perry Hutchison wrote:
> [trimmed some of the lists]
>
> Chris Rees wrote:
>> ... git doesn't work with our workflow.
>
> I'm sure the workflow itself is documented somewhere, but is
> there a good writeup of _how_ git doesn't work with it, e.g. what
> capabilit{y,ies} is/are missing? Seems this might be of interest
> to the git developers, not because they necessarily want to support
> FreeBSD as such, but as an example of a real-world workflow that git
> currently does not handle well.
Peter had something to say about it:
http://wiki.freebsd.org/GitDrawbacks
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 17 November 2012 23:31, Konstantin Belousov wrote: > Git would work well with our workflow. It supports the centralized > repository model, which the project employs right now. It may work with your workflow, but it doesn't work with mine. :-) Right now the source tree isn't very good at building drivers from a full HEAD checkout on a -9 or -8 running system. The include paths end up pulling from the local sys/net directory, for example, rather than falling through to the specified kernel build and kernel source path. So at least for me, working almost exclusively in driver/stack land, I can do sparse check out of only the bits that I'm working on. It lets me get work done without having to run an up to date -HEAD (and keep said install up to date.) I also do development on little old netbooks with SSDs that would make it prohibitive to checkout multiple git trees. No, using git on a USB/CF/etc card doesn't work very well either I'm afraid. I'm sure there are other use cases. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
