* Re: [PATCH] diff and apply: fix singular/plural grammar nit.
From: Jakub Narebski @ 2011-11-27 14:47 UTC (permalink / raw)
To: David Ripton; +Cc: git
In-Reply-To: <4ED23EB5.1030208@ripton.net>
David Ripton <dripton@ripton.net> writes:
> Remove the trailing 's' from "files", "insertions", and "deletions"
> when there is only one of the item.
>
> Signed-off-by: David Ripton <dripton@ripton.net>
> ---
[...]
> - printf(" %d files changed, %d insertions(+), %d
> deletions(-)\n", files, adds, dels);
Whitespace damaged. Please turn off word wrapping (limiting line
width) when sending patches.
> + printf(" %d file%s changed, %d insertion%s(+), %d deletion%s(-)\n",
> + files, (files == 1 ? "" : "s"),
> + adds, (adds == 1 ? "" : "s"),
> + dels, (dels == 1 ? "" : "s"));
> }
First, I think this is an API / plumbing and should not be changed.
But I might be mistaken about that.
Second, it is a perfect example ho to *not* handle plural form in the
presence of internationalization (i18n) efforts. See e.g.
http://www.gnu.org/s/hello/manual/gettext/Plural-forms.html
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH] diff and apply: fix singular/plural grammar nit.
From: Carlos Martín Nieto @ 2011-11-27 14:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Ripton, git
In-Reply-To: <m37h2lmxk9.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
On Sun, Nov 27, 2011 at 06:47:21AM -0800, Jakub Narebski wrote:
> David Ripton <dripton@ripton.net> writes:
>
> > Remove the trailing 's' from "files", "insertions", and "deletions"
> > when there is only one of the item.
> >
> > Signed-off-by: David Ripton <dripton@ripton.net>
> > ---
> [...]
> > - printf(" %d files changed, %d insertions(+), %d
> > deletions(-)\n", files, adds, dels);
>
> Whitespace damaged. Please turn off word wrapping (limiting line
> width) when sending patches.
>
> > + printf(" %d file%s changed, %d insertion%s(+), %d deletion%s(-)\n",
> > + files, (files == 1 ? "" : "s"),
> > + adds, (adds == 1 ? "" : "s"),
> > + dels, (dels == 1 ? "" : "s"));
> > }
>
> First, I think this is an API / plumbing and should not be changed.
> But I might be mistaken about that.
I think somebody already tried to do this not too long ago (don't know
if there as a patch) but the diffstat tool always uses the plural, and
it might break scripts.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] diff and apply: fix singular/plural grammar nit.
From: Frans Klaver @ 2011-11-27 15:41 UTC (permalink / raw)
To: Jakub Narebski, Carlos Martín Nieto; +Cc: David Ripton, git
In-Reply-To: <20111127145033.GA1738@centaur.lab.cmartin.tk>
On Sun, 27 Nov 2011 15:50:33 +0100, Carlos Martín Nieto <cmn@elego.de>
wrote:
> I think somebody already tried to do this not too long ago (don't know
> if there as a patch) but the diffstat tool always uses the plural, and
> it might break scripts.
That would be http://thread.gmane.org/gmane.comp.version-control.git/178316
Frans
^ permalink raw reply
* two branches: keep one difference but merge others forth and back
From: Gelonida N @ 2011-11-27 17:31 UTC (permalink / raw)
To: git
Hi,
Is this possible.
I'd like to have two branches.
If possible I would be able to merge forth and back between both of them.
However I would like, that certain differences will be kept between both
branches.
Is there any way to tell git to permanently ignoring certain commits
from merging?
Example:
---------
Normally shell scripts would have a first line of
'#!/bin/bash',
but in a certain branch I would like that the first lines would be
'#!/usr/local/bin/bash'
All from then on however I'd like to be able to commit on both branches
and to merge from the other branches (and always keep this difference)
What I tried:
-------------
My first naive approach was:
- create shell scripts in master,
- create then a branch named 'my_shell'
- modify first lines of shell scripts in this branch and commit
- checkout master
- merge my_shell to master with merge strategy 'ours'
git pull my_shell -s ours
- now I changed something else in master
- when I try to merge back to branch my_shell I will not only get
the most recent changes done in master, but I will also undo the
changes in line 1 of my shell scripts.
So it seems I am not doing things as one should.
Potential other strategies:
----------------------------
- never commit anything on branch my_shell and just pull regularly
from master to keep it synced.
- commit changes / bug fixes also on branch my_shell, but NEVER merge
back to master. If a change grom my_shell is really needed on master,
then just cherry-pick.
Thanks in advance for suggestions how you would deal with such 'situations'
^ permalink raw reply
* [BUG] difftool falls back to normal diff when used during merge resolution
From: Jakub Turski @ 2011-11-27 18:09 UTC (permalink / raw)
To: git
Hello there,
Just found this behavior, and after a chat on IRC it looks to me like
an actual bug. I have 'git difftool' configured to use vimdiff - and
it worked fine. Despite that config, git still falls back to plain
diff when I launch difftool mid-way through merge conflict resolution.
Here's a reproducable testcase (w/ version 1.7.7.3)
$ mkdir a; cd a; git init; echo A>A; git add A; git commit -m A; git
branch alt; echo AA>A; git commit -am AA; git checkout alt; echo B>A;
git commit -m B; git commit -am B; git checkout master; git merge alt;
git difftool -t vimdiff A
Results:
http://pastie.org/2929336
KT.
^ permalink raw reply
* [PATCH] Make feed title valid utf8
From: Jürgen Kreileder @ 2011-11-27 22:37 UTC (permalink / raw)
To: git
gitweb doesn't properly handle UTF8 site names when generating feed titles.
Signed-off-by: Juergen Kreileder <jk@blackdown.de>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..a2838c3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -7482,7 +7482,7 @@ sub git_feed {
return if ($cgi->request_method() eq 'HEAD');
# header variables
- my $title = "$site_name - $project/$action";
+ my $title = to_utf8($site_name) . " - " . to_utf8($project) . "/$action";
my $feed_type = 'log';
if (defined $hash) {
$title .= " - '$hash'";
--
1.7.5.4
^ permalink raw reply related
* Re: gitweb: in-page errors don't work with mod_perl
From: Jakub Narebski @ 2011-11-27 22:43 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0UuweWoY5ObXgyN9vrOXWrKdNYWuG7CGB0V7HvcuiwRJD+A@mail.gmail.com>
Hello!
Jürgen Kreileder <jk@blackdown.de> writes:
> when gitweb.perl (208a1cc3d3) is run with mod_perl2 (2.0.5-2ubuntu1 on
> Ubuntu 11.10) custom error pages don't work: Any page with status !=
> 200 shows the plain Apache error document instead of a gitweb's error
> page.
Thanks for reporting it. I wonder if it worked at all anytime...
Anyway, does the following patch fixes this issue for you?
-- >8 --
Subject: [PATCH] gitweb: Fix error handling for mod_perl
When gitweb was run with mod_perl2 (using ModPerl::Registry), the
custom error pages don't work: Any page with status != 200 had the
plain Apache error document appended to a gitweb's error page, e.g.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
...
</html><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL ... was not found on this server.</p>
<hr>
<address>Apache/2.0.54 (Fedora) Server at localhost Port 80</address>
</body></html>
When serving gitweb with application/xhtml+xml mimetype this results
in malformed XML and some browsers do not showing output at all.
The solution used by this commit is to tell mod_perl that it is O.K.,
and we handled all errors by ourselves.
This make us not depend in whether there is or not
PerlOptions +ParseHeaders
in Apache configuration section for mod_perl.
Reported-by: Jürgen Kreileder <jk@blackdown.de>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..f51cce1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1239,6 +1239,11 @@ sub run {
run();
+if ($ENV{'MOD_PERL'}) {
+ # mod_perl needs to be told that error page was already created
+ my $r = $cgi->r;
+ $r->status(200);
+}
if (defined caller) {
# wrapped in a subroutine processing requests,
# e.g. mod_perl with ModPerl::Registry, or PSGI with Plack::App::WrapCGI
--
1.7.6
^ permalink raw reply related
* Re: gitweb: 404 links on some blob pages
From: Jakub Narebski @ 2011-11-27 22:44 UTC (permalink / raw)
To: Jürgen Kreileder; +Cc: git
In-Reply-To: <CAKD0UuxBO_Uj4dHr9g3zryO=03_ds0omFFnGY89_MPJGfxLZMA@mail.gmail.com>
Jürgen Kreileder <jk@blackdown.de> writes:
> some blob pages have broken links:
>
> For example, on
> https://git.blackdown.de/?p=contactalbum.git;a=blob;f=Classes/WindowController.m;h=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a;hb=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a
> the blob_plain link for WindowController.m leads to '404 - Cannot find file':
> https://git.blackdown.de/?p=contactalbum.git;a=blob_plain;f=Classes/WindowController.m;hb=b84d1882cb6c3a2d2058cbdd56b2280b48f1690a
That is strange. The check is the same for 'blob' and 'blob_plain'
action...
--
Jakub Narębski
^ permalink raw reply
* [PATCH] gitweb: Output valid utf8 in git_blame_common('data')
From: Jürgen Kreileder @ 2011-11-27 23:52 UTC (permalink / raw)
To: git
With javascript-actions enabled gitweb showed broken author names in
the tooltips on blame pages.
Signed-off-by: Juergen Kreileder <jk@blackdown.de>
---
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..c863afe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6107,7 +6107,9 @@ sub git_blame_common {
-type=>"text/plain", -charset => "utf-8",
-status=> "200 OK");
local $| = 1; # output autoflush
- print while <$fd>;
+ while (my $line = <$fd>) {
+ print to_utf8($line);
+ }
close $fd
or print "ERROR $!\n";
--
1.7.5.4
^ permalink raw reply related
* Re: gitweb: in-page errors don't work with mod_perl
From: Jürgen Kreileder @ 2011-11-28 0:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m339d9mbiu.fsf@localhost.localdomain>
2011/11/27 Jakub Narebski <jnareb@gmail.com>:
> Jürgen Kreileder <jk@blackdown.de> writes:
>
>> when gitweb.perl (208a1cc3d3) is run with mod_perl2 (2.0.5-2ubuntu1 on
>> Ubuntu 11.10) custom error pages don't work: Any page with status !=
>> 200 shows the plain Apache error document instead of a gitweb's error
>> page.
>
> Thanks for reporting it. I wonder if it worked at all anytime...
>
> Anyway, does the following patch fixes this issue for you?
Not really. It does make the errors appear inline on the standard gitweb pages.
But the HTTP status code is broken now: It's always 200 OK.
> Reported-by: Jürgen Kreileder <jk@blackdown.de>
> Signed-off-by: Jakub Narębski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 4f0c3bd..f51cce1 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1239,6 +1239,11 @@ sub run {
>
> run();
>
> +if ($ENV{'MOD_PERL'}) {
> + # mod_perl needs to be told that error page was already created
> + my $r = $cgi->r;
> + $r->status(200);
> +}
> if (defined caller) {
> # wrapped in a subroutine processing requests,
> # e.g. mod_perl with ModPerl::Registry, or PSGI with Plack::App::WrapCGI
> --
> 1.7.6
>
>
Jürgen
^ permalink raw reply
* [PATCH] gitweb: Output site name with valid utf8 in OPML
From: Jürgen Kreileder @ 2011-11-28 1:45 UTC (permalink / raw)
To: git
Signed-off-by: Juergen Kreileder <jk@blackdown.de>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..df747c1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -7699,11 +7699,12 @@ sub git_opml {
-charset => 'utf-8',
-content_disposition => 'inline; filename="opml.xml"');
+ my $title = esc_html($site_name);
print <<XML;
<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
<head>
- <title>$site_name OPML Export</title>
+ <title>$title OPML Export</title>
</head>
<body>
<outline text="git RSS feeds">
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 0/6] echo usernames as they are typed
From: Jeff King @ 2011-11-28 3:53 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSb09kxjvdvz2P-WqU2VtMspaaA8ujTNLJ4+MuCrV=2zsw@mail.gmail.com>
On Sun, Nov 27, 2011 at 10:17:26AM +0100, Erik Faye-Lund wrote:
> > And here's something I've been meaning to do on top: actually echo
> > characters at the username prompt. We can't do this portably, but we can
> > at least stub out a compatibility layer and let each system do something
> > sensible.
>
> Interesting, I've been working on something pretty similar: getting
> rid of getpass usage all together:
>
> https://github.com/kusma/git/tree/work/askpass
>
> My reason to write a getpass replacement was to avoid capping input to
> PASS_MAX, which can be as low as 8 characters (and AFAIK is just that
> on Solaris)...
Yeah, if there are really bad getpass implementations, we would want to
work around them. If we are going to do so, it might make sense to
combine the effort with my getpass_echo wrapper, as they are really the
same function, modulo tweaking the echo settings.
It would also be nice to make getpass a little more predictable. If
/dev/tty can't be opened, glibc's getpass will fall back to writing the
prompt to stderr and reading the password from stdin. But we definitely
don't want to do that in git-remote-curl, where stdin is already talking
a special protocol with the parent fetch process.
So I think it might be best to just write our own getpass. However,
your implementation looks wrong to me:
> diff --git a/password.c b/password.c
> new file mode 100644
> index 0000000..727ed84
> --- /dev/null
> +++ b/password.c
> @@ -0,0 +1,94 @@
> +#include "cache.h"
> +#include "git-compat-util.h"
> +#include "strbuf.h"
> +#include "run-command.h"
> +
> +#ifndef WIN32
> +
> +static void ask_password(struct strbuf *sb, const char *prompt)
> +{
> + struct termios attr;
> + tcflag_t c_lflag;
> +
> + if (tcgetattr(1, &attr) < 0)
> + die("tcgetattr failed!");
> + c_lflag = attr.c_lflag;
This is getting the terminal attributes for stdout. But in many
cases, stdout will not be connected to the terminal (in particular,
remote-curl, as I mentioned above, will have its stdio connected to the
parent fetch process). Stderr is a better guess, as you do here:
> + fputs(prompt, stderr);
but even that is not foolproof. With getpass(), this should work:
git clone ... 2>errors
with the prompt going to the terminal. But it doesn't with your patch.
You really want to open "/dev/tty" on most Unix systems (which is what
getpass() does). I have no idea what would be appropriate on Windows.
> + for (;;) {
> + int c = getchar();
> + if (c == EOF || c == '\n')
> + break;
> + strbuf_addch(sb, c);
> + }
And this is even worse. You're reading from stdin, which will get
whatever cruft is in the pipe coming from the parent process (or may
even cause a hang, as the parent is probably blocking waiting to read
from the child helper).
-Peff
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Junio C Hamano @ 2011-11-28 6:41 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Jeff King, Git
In-Reply-To: <CAMK1S_jbofsWyag3Sospz8wYHqD4Z1Fs0p+MJWi02eCq0e+uHQ@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
>> I actually like the idea of allowing pre-upload-pack hook on git:// and
>> possibly http:// only....
>>
>> One scenario I do not want to see is this. Suppose ...
>
> I'm sorry I started this discussion. I worked around it, though it's
> a bit kludgy, so maybe time to drop the debate.
I do not want you to feel sorry, and I do not understand why you feel that
way.
I think a reasonable and safe way to trigger an action in response to a
request to fetch from a repository _is_ a sensible thing to wish for. So
far, we established that we cannot just simply add pre-upload hook back in
and be done with it, as that is not a safe way. We learned something.
Jeff may be right that any approach based on hooks cannot be made totally
safe. But the discussion can lead to a workable alternative. The "enable
the hook only on git:// and http:// and no other" approach might or might
not be such a workable alternative. The "try talking to a service process
via named pipe, instead of spawning a hook" might or might not be such a
workable alternative. Other possibilities may be there to be explored.
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Jeff King @ 2011-11-28 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, Git Mailing List
In-Reply-To: <7vmxbivw8u.fsf@alter.siamese.dyndns.org>
On Sat, Nov 26, 2011 at 11:51:29PM -0800, Junio C Hamano wrote:
> I personally have a huge problem with shipping an inherently unsafe
> mechanism that is disabled by default even if it is marked with big red
> letters saying that it is unsafe and should not be enabled casually. It
> makes it up to the system administrator to decide what is casual and what
> is not, but when end users are get harmed by a clueless administrator's
> decision, the repercussion will come back to the Git software, not to the
> clueless administrator who enabled an unsafe mechanism in an environment
> where it was not designed to support.
I agree. If we can avoid adding any feature which is even potentially
dangerous, it's good to explore alternatives. At the same time, the
subject of remote fetch hooks has come up before, and I don't think it's
going away. It would be nice to reach more resolution this time.
I also have mild concerns about the current receive-pack hooks. The
thought so far has been "well, you're less likely push into a bad
person's repository". Which is probably true. But it seems like a flaky
thing to base security on, especially in multi-user environments with
shared repositories.
> If the mechanism to notify the external machinery (i.e. counting accesses,
> learning the true destination of a new fetch request and have the fetcher
> wait while the real fetch goes to the origin site) were not via a hook
> that runs as the fetcher but were via something else that runs as the
> owner of that external service (i.e. counting accesses, maintaining the
> proxy object pool), I wouldn't have trouble with the proposal.
>
> For example, upload-pack could write the details of the original request
> to a named pipe to ask the "service" process listening on the other end,
> and wait for its response.
Right, that was the "socket" solution I mentioned earlier. The problem
is that it's a pain to set up. If you really want to have a daemon
running and handling git tasks, then you might as well just have the
whole upload-pack/receive-pack side accessible over a socket (e.g., just
run git-daemon if you don't care about authentication, and
git-over-https if you do).
If you really care about ssh authentication and keeping track of
individual unix users, then one possibility is to run git-daemon
listening on a unix socket, use SO_PEERCRED to get the user on the other
end, and then process everything as a single git user.
For example, imagine Bob and Alice are in the "research" group, and use
a shared central repo. Bob wants to push:
1. Bob runs "git push" on his workstation. Git on the workstation
connects to "ssh bob@server git-receive-pack $repo".
2. git-receive-pack on the server runs as Bob. It notices that
$repo/daemon-socket exists, and runs in "shim" mode, connecting to
the socket and proxying data over the socket.
3. git-daemon, running as the "research" user, listens on the other
end of the socket (and potentially sockets for other repos). It
sees the connection and serves it. The daemon already knows which
repo to serve because it knows which socket Bob connected to. And
it knows it's OK for Bob to access it, because he was able to get
to the socket via filesystem permissions.
The daemon can use getsockopt(SO_PEERCRED) to find out that Bob is
the user, and probably set an environment variable. It can freely
run any hooks, because the hooks are owned by the "research" user,
and that's the user the daemon runs as. Hooks can trust the
environment from the daemon, and can use Bob's identity for further
authorization checks if they want to. IOW, we are roughly at the
same place you would get by connecting over git-over-https.
This naturally extends to "Bob fetches" or "Bob runs his push from the
server". As an added bonus over the usual shared-central-repo model,
malicious users can't just ignore hooks (in the usual shared-repo model,
everybody can write directly to the object db and refs, so hooks are
somewhat advisory).
I suspect people who really care about this use case are already running
git-over-https, possibly with something like gerrit doing some policy
enforcement. I also suspect there are a lot of corporate environments
where they just have a big shared repo, set core.sharedRepository, and
don't worry too much about users hurting each other (in most dev
environments I've seen, people are perfectly willing to fetch and run
make without looking at the diff, so it's sort of a moot point).
People in the latter half would be one of the potential audiences for
the "screw it, just run hooks from the remote repo" flag.
> I actually like the idea of allowing pre-upload-pack hook on git:// and
> possibly http:// only. git-daemon can tell the upload-pack that it is OK
> to run the hook, and the hook can do the things that only the daemon can
> do, never touching what the original requestor would but the repository
> owner would not have an access to.
That's not necessarily safe. Think about a site like kernel.org. The
administrator is the one running the daemon, on behalf of all of the
users. But my impression is that pre-August, developers had shell access
to their own repos and could write their own hook files. So if
git-daemon runs hooks, then any repo owner could run arbitrary code as
the git-daemon, including killing the running daemon and running their
own trojan.
So you really need some way for the admin to say "it's OK, hooks are
locked down and it's safe for them to run". Which again, I was thinking
of as an environment variable.
However, I think for the daemon case, the other alternative I mentioned
earlier is a bit more elegant: an environment variable which doesn't say
"respect the hooks in the repo", but rather "run this _particular_
program as the pre-upload-pack hook". And then the admin doesn't have
to care what's in the repos. The daemon runs some particular program
every time a fetch happens.
It's tempting to say "can't they just replace git-upload-pack with a
shim that does what they want and then runs upload-pack?"[1]. But I
think the answer is no, for the same reason we have hooks at all: they
might want to operate under a lock, or use some data produced by
upload-pack, or make a decision that blocks the fetch.
[1] Actually, I think Sitaram's case may not be a pre-upload-pack hook,
but rather the simple "run before upload-pack" case. Because a
pre-upload-pack would probably feed the set of requested objects to
the hook. But he will want to fetch from the upstream before even
advertising any refs to the client.
> One scenario I do not want to see is this. Suppose there is a company that
> runs more than one project, and one of the projects is so secret that only
> engineers working on the project have access to its repository, while all
> people, including the project-A engineers, in the company have access to
> other repositories. Further suppose that people involved in some or many
> of the general repositories want to do something before a fetch from them
> happens. They will use the pre-upload-hook to implement it if we make it
> available, and their new-hire training course will tell their engineers to
> set the GIT_ALLOW_UNTRUSTED_HOOKS. Perhaps the /etc/skel/profile the
> company gives the new-hires already defines it.
Right. This is a failure of the training course and/or the admin who
wrote the default profile, and is exactly the thing that would be
mentioned in the red flags in the docs. I agree there is a risk of
bone-headed admins, though.
This, btw, is more or less the case I am concerned about _now_ with
receive-pack. With current git, if any of those general repositories is
a shared central repo, then project A is similarly vulnerable to anyone
who can write the hook.
-Peff
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Jeff King @ 2011-11-28 8:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, Git
In-Reply-To: <7vzkfgvjdo.fsf@alter.siamese.dyndns.org>
On Sun, Nov 27, 2011 at 10:41:39PM -0800, Junio C Hamano wrote:
> >> I actually like the idea of allowing pre-upload-pack hook on git:// and
> >> possibly http:// only....
> >>
> >> One scenario I do not want to see is this. Suppose ...
> >
> > I'm sorry I started this discussion. I worked around it, though it's
> > a bit kludgy, so maybe time to drop the debate.
>
> I do not want you to feel sorry, and I do not understand why you feel that
> way.
Agreed. This is a topic that has come up several times before for other
users (GitHub and Gentoo come to mind), and which I've given some
thought to, which is why I'm writing so many words on the subject.
As for your kludge, I took a peek at gitpod. I actually think
intercepting the call to upload-pack is a reasonably sane approach,
since you really don't care what the client says, and just want to run
before anything else (including ref advertisement) happens. It would be
much nicer if git-daemon could take a parameter[1] to an alternate
upload-pack path so you didn't have to play PATH games. That would be a
simple patch with no security ramifications, I think.
-Peff
[1] I mean a command-line parameter or environment varable. Reading it
from the repo config _does_ have security implications.
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Sitaram Chamarty @ 2011-11-28 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git
In-Reply-To: <7vzkfgvjdo.fsf@alter.siamese.dyndns.org>
On Mon, Nov 28, 2011 at 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>>> I actually like the idea of allowing pre-upload-pack hook on git:// and
>>> possibly http:// only....
>>>
>>> One scenario I do not want to see is this. Suppose ...
>>
>> I'm sorry I started this discussion. I worked around it, though it's
>> a bit kludgy, so maybe time to drop the debate.
>
> I do not want you to feel sorry, and I do not understand why you feel that
> way.
Because I did not think it was so complicated...? :-)
> I think a reasonable and safe way to trigger an action in response to a
> request to fetch from a repository _is_ a sensible thing to wish for. So
> far, we established that we cannot just simply add pre-upload hook back in
> and be done with it, as that is not a safe way. We learned something.
> Jeff may be right that any approach based on hooks cannot be made totally
> safe. But the discussion can lead to a workable alternative. The "enable
> the hook only on git:// and http:// and no other" approach might or might
> not be such a workable alternative. The "try talking to a service process
> via named pipe, instead of spawning a hook" might or might not be such a
> workable alternative. Other possibilities may be there to be explored.
There are only 2 cases: git-upload-pack runs as invoking user, or it
runs as some common user/repo owner.
I see pre-upload hooks for case 1 as being hard/impossible to do,
while case 2 is trivial (just check if the hook file owner == UID of
the git-upload-pack process).
Yes, this means pre-upload won't work identically in *all* setups.
But as you said somewhere: perfect is the enemy of good.
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Jeff King @ 2011-11-28 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, Git Mailing List
In-Reply-To: <20111128075107.GA16901@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 02:51:07AM -0500, Jeff King wrote:
> > I actually like the idea of allowing pre-upload-pack hook on git:// and
> > possibly http:// only. git-daemon can tell the upload-pack that it is OK
> > to run the hook, and the hook can do the things that only the daemon can
> > do, never touching what the original requestor would but the repository
> > owner would not have an access to.
>
> That's not necessarily safe. Think about a site like kernel.org. The
> administrator is the one running the daemon, on behalf of all of the
> users. But my impression is that pre-August, developers had shell access
> to their own repos and could write their own hook files. So if
> git-daemon runs hooks, then any repo owner could run arbitrary code as
> the git-daemon, including killing the running daemon and running their
> own trojan.
Actually, depending on how kernel.org (or other similar sites) run the
daemon, this might be an issue even without further patches. By default,
git-daemon lets the enable/disable flag for any service be overridden by
the repo config. So something like this:
# make an evil repo; imagine this is done by a user on a shared
# hosting site which allows shell access.
git init --bare evil &&
cat >evil/hooks/update <<\EOF &&
#!/bin/sh
echo >&2 "executing arbitrary code as `id`"
EOF
git --git-dir=evil config daemon.receivepack true &&
touch evil/git-daemon-export-ok &&
chmod -R 777 evil
# now serve the repo as a daemon running as some other
# user. This simulates the admin of a shared git hosting
# site running git-daemon.
sudo su -c 'git daemon --verbose --base-path="$PWD"' nobody
and then push from anywhere:
$ git push --all git://localhost/evil
...
remote: executing arbitrary code as uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
You can avoid this by setting --forbid-override=receivepack; I wonder if
that should be the default.
-Peff
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Jeff King @ 2011-11-28 8:27 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Junio C Hamano, Git
In-Reply-To: <CAMK1S_hX3fEf1nL28yxASLw_cveJbC5aQRdixgBF6zaPyAEsdA@mail.gmail.com>
On Mon, Nov 28, 2011 at 01:47:44PM +0530, Sitaram Chamarty wrote:
> > Jeff may be right that any approach based on hooks cannot be made totally
> > safe. But the discussion can lead to a workable alternative. The "enable
> > the hook only on git:// and http:// and no other" approach might or might
> > not be such a workable alternative. The "try talking to a service process
> > via named pipe, instead of spawning a hook" might or might not be such a
> > workable alternative. Other possibilities may be there to be explored.
>
> There are only 2 cases: git-upload-pack runs as invoking user, or it
> runs as some common user/repo owner.
I think it is slightly more complicated. You may have a common user, but
that user may or may not trust the contents of the repo on disk (e.g.,
a system daemon serving repos for arbitrary users).
> I see pre-upload hooks for case 1 as being hard/impossible to do,
> while case 2 is trivial (just check if the hook file owner == UID of
> the git-upload-pack process).
The UID check doesn't quite tell you what you want. If I am in a shared
repo situation with a liberal umask and I write a hook, it will have my
UID. But it may have group-write permissions. Other people in my group
can write arbitrary contents to the file, but it will retain my UID, and
git's check will think the code is OK to run.
> Yes, this means pre-upload won't work identically in *all* setups.
> But as you said somewhere: perfect is the enemy of good.
Yes, I think we have to accept inconsistency if we have them at all.
Because such hooks are dangerous in some setups, and OK in others. So no
matter what the rule for determining danger, they will sometimes run and
sometimes not.
-Peff
^ permalink raw reply
* Re: what are the chances of a 'pre-upload' hook?
From: Sitaram Chamarty @ 2011-11-28 9:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git
In-Reply-To: <20111128080145.GB16901@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 1:31 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 27, 2011 at 10:41:39PM -0800, Junio C Hamano wrote:
>
>> >> I actually like the idea of allowing pre-upload-pack hook on git:// and
>> >> possibly http:// only....
>> >>
>> >> One scenario I do not want to see is this. Suppose ...
>> >
>> > I'm sorry I started this discussion. I worked around it, though it's
>> > a bit kludgy, so maybe time to drop the debate.
>>
>> I do not want you to feel sorry, and I do not understand why you feel that
>> way.
>
> Agreed. This is a topic that has come up several times before for other
> users (GitHub and Gentoo come to mind), and which I've given some
> thought to, which is why I'm writing so many words on the subject.
I can see that you have, and I appreciate that.
I was vaguely feeling guilty about *causing* all that extra effort,
because I think it is a bit of a waste of time. I sincerely believe
there is *no* place for shared setups [1] these days, however common
they may be. In fact, if I didn't already believe so, your last few
emails would have convinced me!
I'm amazed to learn in this thread that people apparently even *push*
in such setups!
[1] not just "upload-pack runs as invoking user" but also other
settings like liberal umask, (which you mentioned) and so on.
> As for your kludge, I took a peek at gitpod. I actually think
> intercepting the call to upload-pack is a reasonably sane approach,
Thanks. I wasn't happy at first but now I'm fine with it.
--
Sitaram
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Erik Faye-Lund @ 2011-11-28 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111128035321.GA15640@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 4:53 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Nov 27, 2011 at 10:17:26AM +0100, Erik Faye-Lund wrote:
>
>> > And here's something I've been meaning to do on top: actually echo
>> > characters at the username prompt. We can't do this portably, but we can
>> > at least stub out a compatibility layer and let each system do something
>> > sensible.
>>
>> Interesting, I've been working on something pretty similar: getting
>> rid of getpass usage all together:
>>
>> https://github.com/kusma/git/tree/work/askpass
>>
>> My reason to write a getpass replacement was to avoid capping input to
>> PASS_MAX, which can be as low as 8 characters (and AFAIK is just that
>> on Solaris)...
>
> Yeah, if there are really bad getpass implementations, we would want to
> work around them. If we are going to do so, it might make sense to
> combine the effort with my getpass_echo wrapper, as they are really the
> same function, modulo tweaking the echo settings.
>
My thinking exactly ;)
> It would also be nice to make getpass a little more predictable. If
> /dev/tty can't be opened, glibc's getpass will fall back to writing the
> prompt to stderr and reading the password from stdin. But we definitely
> don't want to do that in git-remote-curl, where stdin is already talking
> a special protocol with the parent fetch process.
>
> So I think it might be best to just write our own getpass. However,
> your implementation looks wrong to me:
>
It probably is, yes. It was a very naive attempt ;)
>> diff --git a/password.c b/password.c
>> new file mode 100644
>> index 0000000..727ed84
>> --- /dev/null
>> +++ b/password.c
>> @@ -0,0 +1,94 @@
>> +#include "cache.h"
>> +#include "git-compat-util.h"
>> +#include "strbuf.h"
>> +#include "run-command.h"
>> +
>> +#ifndef WIN32
>> +
>> +static void ask_password(struct strbuf *sb, const char *prompt)
>> +{
>> + struct termios attr;
>> + tcflag_t c_lflag;
>> +
>> + if (tcgetattr(1, &attr) < 0)
>> + die("tcgetattr failed!");
>> + c_lflag = attr.c_lflag;
>
> This is getting the terminal attributes for stdout. But in many
> cases, stdout will not be connected to the terminal (in particular,
> remote-curl, as I mentioned above, will have its stdio connected to the
> parent fetch process). Stderr is a better guess, as you do here:
>
>> + fputs(prompt, stderr);
>
> but even that is not foolproof. With getpass(), this should work:
>
> git clone ... 2>errors
>
> with the prompt going to the terminal. But it doesn't with your patch.
>
> You really want to open "/dev/tty" on most Unix systems (which is what
> getpass() does).
Yes, you're right. Opening "/dev/tty" is much better. But what happens
for processes started by GUI applications (with no easily observable
tty, if any)? Does open simply fail? If so, is it desirable for us to
fail in that case?
> I have no idea what would be appropriate on Windows.
>
It's pretty similar, but not exactly: CreateFile("CONIN$", ...) or
CreateFile("CONOUT$", ...), depending on if you want the read-handle
or the write-handle... I can probably cook up something a bit more
concrete, though.
But _getch() that we already use always reads from the console
(according to MSDN, I haven't actually tested this myself:
http://msdn.microsoft.com/en-us/library/078sfkak%28v=VS.80%29.aspx).
But I don't think this allows us to fail when no console is attached.
Question is, should we fail in such cases? Windows does have an API to
prompt for passwords in a GUI window... Perhaps fallbacking to those
are the way to go? Something like:
if (GetConsoleWindow()) {
/* normal console-stuff */
} else {
/* call CredUIPromptForWindowsCredentials(...) instead */
}
This might be nicer towards GUI tools, but it requires us to
explicitly ask for a password (and possibly a username at the same
time)...
>> + for (;;) {
>> + int c = getchar();
>> + if (c == EOF || c == '\n')
>> + break;
>> + strbuf_addch(sb, c);
>> + }
>
> And this is even worse. You're reading from stdin, which will get
> whatever cruft is in the pipe coming from the parent process (or may
> even cause a hang, as the parent is probably blocking waiting to read
> from the child helper).
>
Yeah, thanks for pointing these glitches out ;)
^ permalink raw reply
* Re: Switch from svn to git and modify repo completely
From: Matthias Fechner @ 2011-11-28 10:10 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Alexey Shumkin
In-Reply-To: <4ED21756.70705@fechner.net>
Am 27.11.11 11:56, schrieb Matthias Fechner:
> git clone gitrepo.git tofilter.git
one additional note.
To get it really working you should execute:
git clone file://gitrepo.git tofilter.git
And later if you copy it to a bare repo:
git clone --bare file://tofiler.git barerepo.git
This will ensure that removed files are not in the cloned repository.
Bye,
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Is there a "--follow" equvalent argument to git-rev-list?
From: Steinar Bang @ 2011-11-28 10:37 UTC (permalink / raw)
To: git
I'm trying to make emacs vc log (`C-x v l') show the full history of git
versioned files.
In my first attempt, I tried adding a "--follow" argument to "git log"
in the vc-git-print-log message. This made `C-x v l' show the full log.
But the problem with this solution was that commands done from the log,
such as diffing (a very convenient way to do diffs, when the "version
numbers" are sha1 hashes...), showing a particular revision, or
annotating from that revision and back, didn't work. See the comment at
the end of this bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756
Today I decided to take another peek at this, but vc-git.el in the emacs
23.1 version of the file, now uses "git rev-list" instead of "git log"
to get the revision list.
And "git rev-list" doesn't seem to have anything similar to
"--follow"...? At least I haven't found it.
The man page doesn't contain the text "renam".
Guessing at what the man page has meant, I've tried adding the "--all"
and "--full-history" arguments, but `C-x v l' still only shows history
back to the last move.
Is there an argument to "git rev-list" that will make it track across
renames? Or is this only possible with "git log --follow"?
Thanks!
- Steinar
^ permalink raw reply
* Re: Infinite loop in cascade_filter_fn()
From: Carlos Martín Nieto @ 2011-11-28 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Henrik Grubbström, Git Mailing list
In-Reply-To: <7vy5v2wleb.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4081 bytes --]
On Sat, Nov 26, 2011 at 02:48:12PM -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > diff --git a/convert.c b/convert.c
> > index 86e9c29..c050b86 100644
> > --- a/convert.c
> > +++ b/convert.c
> > @@ -880,20 +880,29 @@ static int lf_to_crlf_filter_fn(struct stream_filter *filter,
> > const char *input, size_t *isize_p,
> > char *output, size_t *osize_p)
> > {
> > - size_t count;
> > + size_t count, o = 0;
> > + static int want_lf = 0;
>
> I do not think we want function scope static state anywhere in the cascade
> filter chain, as it will forbid us from running more than one output chain
> at the same time in the future. I think the correct way to structure it
> would be to create lf_to_crlf_filter as a proper subclass of stream_filter
> (see how cascade_filter_fn() casts its filter argument down to an instance
> of the cascade_filter class and uses it to keep track of its state) and
> keep this variable as its own filter state [*1*].
Good point, here's a patch that does that.
cmn
--- 8< ---
Subject: [PATCHv2] convert: track state in LF-to-CRLF filter
There may not be enough space to store CRLF in the output. If we don't
fill the buffer, then the filter will keep getting called with the same
short buffer and will loop forever.
Instead, always store the CR and record whether there's a missing LF
if so we store it in the output buffer the next time the function gets
called.
Reported-by: Henrik Grubbström <grubba@roxen.com>
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
convert.c | 50 +++++++++++++++++++++++++++++++++++++-------------
1 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/convert.c b/convert.c
index 86e9c29..1c91409 100644
--- a/convert.c
+++ b/convert.c
@@ -876,24 +876,39 @@ int is_null_stream_filter(struct stream_filter *filter)
/*
* LF-to-CRLF filter
*/
+
+struct lf_to_crlf_filter {
+ struct stream_filter filter;
+ int want_lf;
+};
+
static int lf_to_crlf_filter_fn(struct stream_filter *filter,
const char *input, size_t *isize_p,
char *output, size_t *osize_p)
{
- size_t count;
+ size_t count, o = 0;
+ struct lf_to_crlf_filter *lfcrlf = (struct lf_to_crlf_filter *) filter;
+
+ /* Output a pending LF if we need to */
+ if (lfcrlf->want_lf) {
+ output[o++] = '\n';
+ lfcrlf->want_lf = 0;
+ }
if (!input)
- return 0; /* we do not keep any states */
+ return 0; /* We've already dealt with the state */
+
count = *isize_p;
if (count) {
- size_t i, o;
- for (i = o = 0; o < *osize_p && i < count; i++) {
+ size_t i;
+ for (i = 0; o < *osize_p && i < count; i++) {
char ch = input[i];
if (ch == '\n') {
- if (o + 1 < *osize_p)
- output[o++] = '\r';
- else
- break;
+ output[o++] = '\r';
+ if (o >= *osize_p) {
+ lfcrlf->want_lf = 1;
+ continue; /* We need to increase i */
+ }
}
output[o++] = ch;
}
@@ -904,15 +919,24 @@ static int lf_to_crlf_filter_fn(struct stream_filter *filter,
return 0;
}
+static void lf_to_crlf_free_fn(struct stream_filter *filter)
+{
+ free(filter);
+}
+
static struct stream_filter_vtbl lf_to_crlf_vtbl = {
lf_to_crlf_filter_fn,
- null_free_fn,
+ lf_to_crlf_free_fn,
};
-static struct stream_filter lf_to_crlf_filter_singleton = {
- &lf_to_crlf_vtbl,
-};
+static struct stream_filter *lf_to_crlf_filter(void)
+{
+ struct lf_to_crlf_filter *lfcrlf = xmalloc(sizeof(*lfcrlf));
+ lfcrlf->filter.vtbl = &lf_to_crlf_vtbl;
+ lfcrlf->want_lf = 0;
+ return (struct stream_filter *)lfcrlf;
+}
/*
* Cascade filter
@@ -1194,7 +1218,7 @@ struct stream_filter *get_stream_filter(const char *path, const unsigned char *s
else if (output_eol(crlf_action) == EOL_CRLF &&
!(crlf_action == CRLF_AUTO || crlf_action == CRLF_GUESS))
- filter = cascade_filter(filter, &lf_to_crlf_filter_singleton);
+ filter = cascade_filter(filter, lf_to_crlf_filter());
return filter;
}
--
1.7.8.rc3.31.g017d1
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
* Re: [BUG] difftool falls back to normal diff when used during merge resolution
From: David Aguilar @ 2011-11-28 11:16 UTC (permalink / raw)
To: Jakub Turski; +Cc: git@vger.kernel.org
In-Reply-To: <CAHWJSOSB768hWsNqrR559wef3-k_yZ=TjS_mxfj3TxXdgwm5iQ@mail.gmail.com>
On Nov 27, 2011, at 10:09 AM, Jakub Turski <yacoob@gmail.com> wrote:
> Hello there,
>
> Just found this behavior, and after a chat on IRC it looks to me like
> an actual bug. I have 'git difftool' configured to use vimdiff - and
> it worked fine. Despite that config, git still falls back to plain
> diff when I launch difftool mid-way through merge conflict resolution.
>
> Here's a reproducable testcase (w/ version 1.7.7.3)
>
> $ mkdir a; cd a; git init; echo A>A; git add A; git commit -m A; git
> branch alt; echo AA>A; git commit -am AA; git checkout alt; echo B>A;
> git commit -m B; git commit -am B; git checkout master; git merge alt;
> git difftool -t vimdiff A
>
> Results:
> http://pastie.org/2929336
I think this is an unfortunate case where the implementation leaks
into the user experience.
I haven't checked, but I'm pretty sure this is because
GIT_EXTERNAL_DIFF has no affect when the conflicts exist.
git mergetool can be used in this situation.
We could do a check up front in difftool to see whether conflicts
exist and exit with an error message. The difftool script is quite
small and basically a very thin wrapper around git diff, though, so I
do hesitate before making it more complicated.
anyways, try "git mergetool".
--
David
^ permalink raw reply
* Re: [PATCH 0/6] echo usernames as they are typed
From: Jeff King @ 2011-11-28 11:31 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <CABPQNSbLvWh-ivaqBk-Du+kwZvV3t+ajEJhHATRzyGZbHYyM=Q@mail.gmail.com>
On Mon, Nov 28, 2011 at 10:36:21AM +0100, Erik Faye-Lund wrote:
> > You really want to open "/dev/tty" on most Unix systems (which is what
> > getpass() does).
>
> Yes, you're right. Opening "/dev/tty" is much better. But what happens
> for processes started by GUI applications (with no easily observable
> tty, if any)? Does open simply fail? If so, is it desirable for us to
> fail in that case?
Yes, the open will fail (on Linux, I get ENXIO).
And yes, we should fail in that case. getpass() will generally return
NULL in that instance, and the current implementation of git_getpass()
will die(), explaining that we could not get the password.
> > I have no idea what would be appropriate on Windows.
>
> It's pretty similar, but not exactly: CreateFile("CONIN$", ...) or
> CreateFile("CONOUT$", ...), depending on if you want the read-handle
> or the write-handle... I can probably cook up something a bit more
> concrete, though.
OK, that maps to the /dev/tty concept quite well. Though I suspect the
code for turning off character echo-ing is going to also be different.
> But _getch() that we already use always reads from the console
> (according to MSDN, I haven't actually tested this myself:
> http://msdn.microsoft.com/en-us/library/078sfkak%28v=VS.80%29.aspx).
> But I don't think this allows us to fail when no console is attached.
> Question is, should we fail in such cases? Windows does have an API to
> prompt for passwords in a GUI window... Perhaps fallbacking to those
> are the way to go? Something like:
>
> if (GetConsoleWindow()) {
> /* normal console-stuff */
> } else {
> /* call CredUIPromptForWindowsCredentials(...) instead */
> }
Certainly on non-Windows something like that would not be welcome. The
user can already have specified GIT_ASKPASS if they don't have a
terminal. And once the credential-helper code is in, they can use a
platform-specific helper that provides a nice dialog if they want it.
So I would say trying to do something graphical would be surprising and
unwelcome. But then, I am a very Unix-y kind of guy. Maybe on Windows
something like that would be more favorable. I'll leave that decision to
people who know more.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox