headers
Graham Dumpleton | 1 Aug 01:07
Picon

[Trac] Re: Google Groups is broken?


Google Groups has been having problems lately. A few weeks ago the
search feature broke and search results wouldn't show anything recent.
This appears to have been fixed in the last few days though. It is
possible there were other consequences from the problems they were
having. So, maybe you were seeing some of these problems.

Graham

On Aug 1, 1:16 am, "Noam Tamim" <noa...@...> wrote:
> I think I ran into another symptom of the same problem: I posted two
> messages to this list using GG, and they didn't even appear in the list of
> messages I posted. After nobody replied to them for a few days I subscribed
> to this list instead, resent the messages, and got immediate responses.
>
> Noam.
>
> On 7/31/07, Daniel Serodio (lists) <daniel.lis...@...> wrote:
>
>
>
> > Lots of messages can't be seen from the Google Groups website; for
> > example, a
> > thread titled "Merge ReportPluginPatch" I started on 26/7/2007 12:16 can't
> > be
> > seen in the website, neither browsing nor searching for
> > "ReportPluginPatch".
>
> > Is this some sort of configuration error, or is it a Google Groups
> > problem?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent | 1 Aug 01:29
Picon
Favicon

[Trac] Re: Encrypted WIKI pages


Well, let me try to explain the feature again.  The intent is to store
passwords and to do so in a way that isn't just the information being
encrypted on transmission from serverside to browser, but to not have
the information available in plaintext to begin with.  It would be
similar to sending email to someone with a PGP key, but having the
email stored in a public area.  Still secure because noone has the
key.  So in the event of storing information like this within the
wiki, even if I am able to get an account level password with
permissions to view a specific page, I still need to do something
else.

My personal suggestion was to just upload a password protected zip
file to the wiki and be done with it, but the usability wasn't simple
enough.  :)

But regardless, doing this all server side or client side is
irrelevant if the encryption key and methodology are a shared secret.
YES, I agree that it's not the most sensible feature in the world, but
based on the Rails encrypt-a-wiki article I posted as well as the
Javascript example I posted, there's at least someone out there with a
similar idea, so I'm not so sure the feature doesn't make sense.
Whether this feature is used in conjunction with something server-side
or not is debatable, but the idea of a form-field and button that says
Encrypt me on the Wiki-Edit screen and a form-field and button that
says Decrypt me on the Wiki-View screen doesn't seem that intrusive
while still being useful, requiring less configuration and admin
overhead than dealing with page level security.

All that said, I respect your viewpoint and actually agreed with it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent | 1 Aug 01:30
Picon
Favicon

[Trac] Re: Encrypted WIKI pages


Oh, and in this case, it's an internal wiki behind a VPN+firewall.
Access and making sure that the information isn't stored in a
compromised format is the issue as I understand it.

On Jul 31, 3:52 pm, Noah Kantrowitz <kan...@...> wrote:
> This feature really makes little sense. The correct way to do this is
> server-side authorization controls. SSL provides transport security
> already. The "once the users password is cracked" issue is
> orthogonal, and means you need a better authentication system than
> simple passwords. I would recommend a two-factor system, and I know
> RSA's SecurID can be integrated with Apache.
>
> --Noah
>
> On Jul 31, 2007, at 6:40 PM, Vincent wrote:
>
>
>
> > I would tend to agree with you.  In fact I completely agreed with you
> > until I looked into this a bit.  And yes, ultimately, you're kind of
> > right - end-to-end security and HTML isn't quite consistent.  But in
> > the event of hey I want to post a message and provide an easy way to
> > encrypt/decrypt it if I have the key actually seems reasonable to me.
> > It prevents data from being stored in the clear in the wiki or in a
> > file.  In fact, it's out in the open - it's the encryption key that
> > has the be known.
>
> > In this case, the context-dependent permissions system isn't what is
> > desired.  The client doesn't want the permission to be user-specific
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vincent | 1 Aug 01:34
Picon
Favicon

[Trac] trac-admin wiki import question


I am looking to import from an existing MediaWiki installation to
Trac.  I've found the mediawiki2trac.py script (see http://trac.edgewall.org/ticket/5241
as the script referenced in the FAQ is out of date with respect to
mediawiki) that helps things, but when I look at it, it doesn't seem
to address attachments.  Also, it's unclear to me whether or not the
trac-admin wiki load command will wipe out everything that is in the
wiki already or if it will only add things based on the namespace
described by the wiki file I am importing?

I don't want to blow away anything that I have already.  How do deal
with attachments and how to deal with namespace collisions?

Vincent

P.S.  Sorry for all the posting today.  I'm feeling a bit randy about
Trac today.  :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@...
To unsubscribe from this group, send email to trac-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Noah Kantrowitz | 1 Aug 01:50
Picon
Favicon

[Trac] Re: Encrypted WIKI pages


If you really insist on this otherwise silly feature, you should look  
at one of the Fx/GPG integration plugins. FireGPG is the first that  
comes to mind. Doing this is kind of multistep security is very  
broken and should be regarded as worthless when compared to a real  
security solution. I can illustrate exactly how it is broken, but I  
would really prefer you take my word on it. Security by obscurity is  
not a replacement for a well designed authn/z solution.

--Noah

On Jul 31, 2007, at 7:29 PM, Vincent wrote:

>
> Well, let me try to explain the feature again.  The intent is to store
> passwords and to do so in a way that isn't just the information being
> encrypted on transmission from serverside to browser, but to not have
> the information available in plaintext to begin with.  It would be
> similar to sending email to someone with a PGP key, but having the
> email stored in a public area.  Still secure because noone has the
> key.  So in the event of storing information like this within the
> wiki, even if I am able to get an account level password with
> permissions to view a specific page, I still need to do something
> else.
>
> My personal suggestion was to just upload a password protected zip
> file to the wiki and be done with it, but the usability wasn't simple
> enough.  :)
>
> But regardless, doing this all server side or client side is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Noah Kantrowitz | 1 Aug 01:53
Picon
Favicon

[Trac] Re: Encrypted WIKI pages


This is a different issue than obfuscating data. You are talking  
about making a webapp that doesn't trust the server. The Web (as  
defined as HTML+JS+CSS+HTTP+etc) is not designed to provide this kind  
of end-to-end security, and attempts to layer it on top are fraught  
with peril. Solutions to this problem are numerous and varied, but  
they will require a better underlying system.

--Noah

On Jul 31, 2007, at 7:30 PM, Vincent wrote:

>
> Oh, and in this case, it's an internal wiki behind a VPN+firewall.
> Access and making sure that the information isn't stored in a
> compromised format is the issue as I understand it.
>
> On Jul 31, 3:52 pm, Noah Kantrowitz <kan...@...> wrote:
>> This feature really makes little sense. The correct way to do this is
>> server-side authorization controls. SSL provides transport security
>> already. The "once the users password is cracked" issue is
>> orthogonal, and means you need a better authentication system than
>> simple passwords. I would recommend a two-factor system, and I know
>> RSA's SecurID can be integrated with Apache.
>>
>> --Noah
>>
>> On Jul 31, 2007, at 6:40 PM, Vincent wrote:
>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Martin | 1 Aug 08:45
Picon

[Trac] Customize error pages


Hi,

is there a way to customize error pages?

My trac-installation allows WIKI_VIEW (and other permissions) only to
registered users. So I wanted to ask, how I can customize the
Forbidden-page to something like "Please register / login to view
wiki".

Second question, is there a plugin that registration has to be
permitted by the admin? Currently I use the Accoutmanager-plugin and
tracd.

BR

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@...
To unsubscribe from this group, send email to trac-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
jmt4b04d4v | 1 Aug 09:39
Picon

[Trac] Re: Spanish Manual


On 31 jul, 15:01, juanmatias <juanmat...@...> wrote:
> Well, I'm looking for TRAC spanish manuals or handbooks. Anyone knows
> where can I find it?

Currently, there aren't official translations of Trac documentation
(TracGuide / wiki-default).

I have plans to continue the translation of ''wiki-default'' pages
(including documentation) in http://trac-hacks.org/wiki/TracSpanishTranslation
but currently I'm very busy (maybe in a couple of weeks).

Any help would be appreciated.
--------------------------------------------------------
Johans Marvin Taboada Villca    -`^_^´- .o0O( 2007-04-24, Bienvenida
Bebecita )
--------------------------------------------------------
Adm. Laboratorio de Desarrollo de Software
Carreras de Informática y Sistemas
UMSS, Cochabamba
Bolivia
--------------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@...
To unsubscribe from this group, send email to trac-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 2 comments |
headers
jmt4b04d4v | 1 Aug 10:06
Picon

[Trac] Re: Remote SVN Repository followup


On 31 jul, 16:51, cobwebsmasher <cobwebsmas...@...> wrote:
> Hi.  Saw a thread about trying to use remote SVN Repositories and wanted to throw my 2 cents in, apologies if
the 2 cents are an unnecessary tip.

This 2 cents can be really valuable (for documentation purposes in
this ML).

> My understanding is that Trac HAS to be pointing to a local version of SVN.  I'm not sure why it would be an
issue to refer to an NFS mount of said SVN repository (well I can think of a few reasons, but that's not what
I'm here to talk about), but I've been warned off of that path.
>
> The path I ended up taking was utilizing svnsync (http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt)
>
> Using svnsync to create a read only repository on the machine that my Trac installation lived on (and
pointed to) works wonderfully.  OCASSIONALLY, I have run into issues where the node_changes database
goes wonky and I have to clear those entries and let Trac rebuild them again (using trac-admin resync
supposedly, but I always seem to get a strange error message).

As this solution seems more naturally than using Remote SVN Access
(RA), I think it's worth to mention more about the error message you
pointed, maybe it can be fixed, maybe it could prevent us from using
this solution.

Best regards,
--------------------------------------------------------
Johans Marvin Taboada Villca    -`^_^´- .o0O( 2007-04-24, Bienvenida
Bebecita )
--------------------------------------------------------
Adm. Laboratorio de Desarrollo de Software
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Sokoll | 1 Aug 10:12
Picon
Favicon

[Trac] XMLRPC plugin and 0.11


Hello,

$SUBJECT looks like a catch-22. In http://trac-hacks.org/ticket/1075,
the ticket points to Eclipse (Mylyn), but their bugzilla points back to
trac.
I'd like to have XMLRPC running, as it is very useful, especially in
conjuction with Mylyn.
Any thoughts?

Rainer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users@...
To unsubscribe from this group, send email to trac-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 4 comments |

Gmane