You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(3) |
Aug
(24) |
Sep
(12) |
Oct
(13) |
Nov
(5) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <da...@ch...> - 2011-03-21 01:25:24
|
You are listed as the contact for a SpamAssassin plugin on http://wiki.apache.org/spamassassin/CustomPlugins Please update your description of your SpamAssassin plugin on http://wiki.apache.org/spamassassin/CustomPlugins to change the line "Updated: Old" to "Updated: YYYY-MM-DD" to represent today's date. We have had problems with unmaintained SpamAssassin addons becoming harmful, so I'm planning to start deleting plugins listed on this page without a reasonably recent date. |
From: Dave B. <da...@br...> - 2008-01-26 16:40:26
|
We now have a Konfidi plugin for SpamAssassin, which makes it actually=20 practical now to start filtering email using Konfidi! This completely=20 obsoletes the old "cli-filter" binary. Mail::SpamAssassin::Plugin::Konfidi is the main module and it relies on=20 Mail::SpamAssassin::Plugin::OpenPGP for authentication. The next major=20 step is to support authentication via SPF and DKIM (for which there are=20 already SpamAssassin modules). For instructions on how to install and=20 start using it, see http://konfidi.org/wiki/Setup_SpamAssassin I'm always eager to help anyone who has questions trying to set it up,=20 and anyone who wants to help develop Konfidi. http://konfidi.org/ --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: A. S. <sc...@gm...> - 2007-06-28 13:20:31
|
Nice. On 6/28/07, Dave Brondsema <da...@br...> wrote: > > http://advogato.org/person/argp/diary.html?start=8 > > Very flattering Konfidi reference... if only I had the time to work on > research & paper-writing! Perhaps I can go to grad school and work on > Konfidi theory one of these days. > > > -- > Dave Brondsema > Software Developer > Cornerstone University > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Konfidi-devel mailing list > Kon...@li... > https://lists.sourceforge.net/lists/listinfo/konfidi-devel > > > |
From: Dave B. <da...@br...> - 2007-06-28 12:53:23
|
http://advogato.org/person/argp/diary.html?start=3D8 Very flattering Konfidi reference... if only I had the time to work on research & paper-writing! Perhaps I can go to grad school and work on Konfidi theory one of these days. --=20 Dave Brondsema Software Developer Cornerstone University |
From: Dave B. <da...@br...> - 2007-05-05 02:24:18
|
The website has now been updated for this release. http://konfidi.org/wiki/Server_Setup_Instructions has been changed the most and is most relevant for these releases. Feel free to ask here if you have any questions Dave Brondsema wrote: > The following server components have been released. It should be easie= r > to get up and running, many bugs have been fixed, output format has > changed, and code has been simplified (PGP pathfinding does not happen > at the server at all). The installation documentation hasn't been > updated on the wiki, but I will try to do so soon. >=20 > http://test-server.konfidi.org is using the latest releases and the > example links on that page work. >=20 > trustserver 1.1.0 - service daemon that does the trust value computatio= n > trustserver frontend 1.1.0 - a web interface to the trustserver > python_module 1.0.0 - python module used to query the trustserver > simple-client 1.1.0 - script to load FOAF files into the trustserver >=20 > Download from http://sourceforge.net/project/showfiles.php?group_id=3D1= 66101 >=20 > I'm getting close to having a SpamAssassin module for Konfidi, which > will make will be easier for people to setup and use than the old > 'cli-filter'. >=20 --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2007-04-28 04:03:59
|
The following server components have been released. It should be easier to get up and running, many bugs have been fixed, output format has changed, and code has been simplified (PGP pathfinding does not happen at the server at all). The installation documentation hasn't been updated on the wiki, but I will try to do so soon. http://test-server.konfidi.org is using the latest releases and the example links on that page work. trustserver 1.1.0 - service daemon that does the trust value computation trustserver frontend 1.1.0 - a web interface to the trustserver python_module 1.0.0 - python module used to query the trustserver simple-client 1.1.0 - script to load FOAF files into the trustserver Download from http://sourceforge.net/project/showfiles.php?group_id=3D166= 101 I'm getting close to having a SpamAssassin module for Konfidi, which will make will be easier for people to setup and use than the old 'cli-filter'. --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2007-04-03 03:46:30
|
Mail::SpamAssassin::Plugin::OpenPGP (see http://search.cpan.org/perldoc?Mail::SpamAssassin::Plugin::OpenPGP) is a SpamAssassin plugin that validates PGP signed email. It also adds some mail-specific validation: it requires the From: address to be one of the addresses on the signer's key, and that the Date: is close to the date of the signature. It's only version 1.0.0 and I'm not even using it myself (yet), but it passes 17 functional/acceptance tests. This is part of my work to migrate the C++ 'cli-filter' mail filter to SpamAssassin and to split it up into several modules, separating authentication modules from a Konfidi/trust module. --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2007-03-06 20:35:09
|
FYI. If anyone else on this list is interested in joining/following the FOAF Whitelisting project discussion, please join the foaf-dev list. -- Dave Brondsema Software Developer Cornerstone University |
From: Kjetil K. <kj...@op...> - 2007-01-31 13:22:00
|
On Wednesday 31 January 2007 04:38, Dave Brondsema wrote: > See > http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/FOAFWhite >listing and my comment at the bottom. Yeah, that's my proposal, but I did reference konfidi.org too. Actually, I think konfidi is how it should be done in an ideal world. But I think I may have the most trusted PGP key among FOAF geeks around, and the intersection between those two groups are too small, it would be much more reasonable at this point to add email addresses manually to a whitelist than use konfidi. Which is kinda sad, because I'd like to have much more widespread adoption of both PGP and FOAF, but the usability of PGP is far from "there yet" (I suppose you've read the seminal paper "Why Johnny can't encrypt" from a few years back and "Why Johnny still can't encrypt" from last year). So, I feel that realistically, there is little chance of konfidi reaching critical mass by starting out with the very well thought out and elaborate architecture that you have. Sad it is, but I think it needs to be built the other way around. There are two problems with the simple FOAF whitelist approach, one is that spammers can forge a well-known address into the From field, the other is that they can pollute the triple-store with foaf:knows statements. The PGP WOT provides a solution to both problems, and so you guys have got it right, but I think we need to build the system the other way around, first we make something that is "good enough", then watch spammer's responses. We could for example be conservative in building the triple-store, and we could combine it with SPF or DomainKeys, which is reasonably widespread. Then, we could let the final trust metric depend upon what kind of verification and authentication method used, thus encouraging people to use stronger methods. The funny thing about spammers is that they often don't crack things even if it is rather trivial to do. E.g. CAPTCHAs, they can be relatively simple. We might not need very elaborate architectures to be effective. BTW, I showed konfidi to timbl last week, as I visited MIT. :-) Cheers, Kjetil -- Kjetil Kjernsmo Semantic Web Specialist Opera Software ASA |
From: Dave B. <da...@br...> - 2007-01-31 03:39:05
|
See http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/FOAFWhitelist= ing and my comment at the bottom. Via http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects (via http://dannyayers.com/2007/01/30/semantic-web-community (via http://planetrdf.com) ) --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2007-01-06 22:52:13
|
I moved konfidi.org hosting from sf.net to my dreamhost account (which has unlimited domains, and plenty of bandwidth available). I upgraded MediaWiki from 1.6.5 to 1.8.2 The website should be A LOT FASTER now. Moreover, Atom & RSS feeds on http://konfidi.org/wiki/Special:Recentchanges now work. Search works now= =2E --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2007-01-03 00:16:16
|
Some time ago sourceforge changed the SVN setup. Existing checkouts will mostly work (I couldn't commit a `svn copy` though). However, it would be good to update it like this (being in the root of your checkout folder): svn switch --relocate https://svn.sourceforge.net/svnroot/konfidi https://konfidi.svn.sourceforge.net/svnroot/konfidi http://konfidi.org/wiki/SVN has the new/correct url. --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2006-12-05 04:17:04
|
Dave Brondsema wrote: > I added Audun J=F8sang (and L Jean Camp) to > http://konfidi.org/wiki/Research. He's got a *lot* of papers that look= > good. I have only skimmed a few so far though >=20 > http://sky.fit.qut.edu.au/~josang/ > http://sky.fit.qut.edu.au/~josang/papers/JP2005-APCCM.pdf > http://sky.fit.qut.edu.au/~josang/papers/JIB2007-DSS.pdf >=20 >=20 Haven't read those yet, but found a bundle of stuff over the past few day= s. I did read Valuation of Trust in Open Networks <http://citeseer.ist.psu.edu/beth94valuation.html> Beth, Borcherding, Klein 1994, which is pretty good, especially considering its age. I've made it the first full entry in a comparative table at http://konfidi.org/wiki/Distributed_Trust_Algorithms > It'd be cool if there were some forum for Internet Trust people to talk= , > like there are for Internet Identity people (e.g. > http://identitygang.org/ http://groups.google.com/group/idworkshop) >=20 Turns out there is. (The internet is too big... things like this should hide from me for years!) http://trustcomp.org/ is associated with the ACM, and includes a yahoo group for discussion. Plus it has a comparison of data models at http://trustcomp.org/Trustcomp-trust-values.html --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Graham H. <gjh...@be...> - 2006-12-04 13:20:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave, Thanks for a prompt response, much appreciated ... >> I jumped through the hoops and now have a konfidi installation up >> and running > Cool! Just by way of some general feedback: Initially, I couldn't get pyme to compile in either OS X or Centos 4.3 (the C compilation failed). I had to resort to fishing out a Linux Python 2.4 binary from a Debian distro. However, upgrading to SWIG 1.3.29 cured the compilation problem and I now have konfidi running on my OS X laptop. >> What's my next step in exercising the facility? > Konfidi hasn't had much application outside of email filtering (and > even > that has had very limited deployment). It might take some > enhancements > to Konfidi to meet your use-case. Understood, and expected. > The first thing that comes to mind would be that you may want an > authentication > system other than OpenPGP. OpenID would be my choice in my next > webapp That's a good suggestion. I picked up the OpenID server code just the other day, so I'll give it some detailed attention. >> Additionally, some have expressed a wish to have multiple "domains" >> of trust (the usual: "Alice trusts Bob strongly on PHP matters but >> weakly on Perl") and they would also like trust to propagate across >> members. Konfidi seems to fit the bill. I'm also investigating > > Yes, topics should work well for that. We haven't implemented support > for topic hierarchies, but thats on our wishlist There's a useful, thought-provoking piece by Clay Shirky[1] on tagging vs ontologies in which he suggests that hierarchies are useful in only some domains. From his characterisation it would seem that "trust topics" isn't one of the domains amenable to hierarchical organisation. However, I haven't yet found a tagging solution which suits me, clouds and interminable lists of words just don't seem to cut it. More thinking required on my part. > I hadn't heard of Pymmetry, I'll look into it. Sorry, I should have at least provided a link[2]. It's a Python implementation of the Advogato trust metric, that's all. > There are some people researching multi-axis trust models, namely > Patricia Victor. See http://konfidi.org/wiki/Research Her second > axis is > consistency/uncertainty. Thanks, I will take a look at that work. I wonder if there's something to be gained from revisiting Tversky and Kahneman's[3] work on the meaning of probabilility and also Jonathan St. BT Evans'[4] work on rationality and reasoning. I'll have to dig out some references. > We started with a single 0-1 range for our trust model for > simplicity's > sake (it could even be interpreted as probabilistic or Bayesian). It occurred to me later that it would be easier to coarsen a fine- grain metric than to add detail to a coarse one. > The interpretation of the 0-1 range is defined by which algorithm is > used in the trustserver (they're called TrustStragies there). So you > could have an implementation that treats them on a bell curve rather > than linearly. As long as the users understand what a 0.8, for > example, > will mean. I should have been more explicit. (I was probably just idly waving my credentials as a cognitive psychologist / cognitive scientist). The Gaussian curve is generally associated with population statistics, whereas an individual's performance can follow a U-shaped function, broadly characterisable by relatively sharp changes in two areas, either side of the median. Your point about "as long as the users understand what a 0.8 is" is important. I don't think it means that we can say they trust someone twice as much as 0.4 value. The cognitive processing is more likely to be symbolic rather than numeric, hence my interest in the Advogato three-valued system which seems to reflect broadly the three areas of a U-shaped function (I'm using a /very/ broad brush). Konfidi allows me to explore different approaches, that is useful. > A few of those features are probably broken. Fair enough. I have access to a Python manual :-) > The Frontend is just a web interface to a TrustServer daemon process > that does the real work. See the diagram Ah yes. I forgot to return the upper levels after grubbing around in the detail. Thanks for reminding me about the system diagram. > to populate the TrustServer with some data, run clients/simple/ > trunk/load_rdf.py in a directory with some .rdf files. See http:// > konfidi.org/wiki/Create_a_FOAF_file for the format it > expects. Again, thanks for that. In the course of getting Konfidi running on my laptop, I took another look at the code and found the scripts to kick off the Trustserver but knowing what to feed it with is crucial. That will save me some time. This is all looking very promising. Thanks again for the info, I'll dig a bit deeper. Cheers, Graham. [1] Ontology is Overrated: Categories, Links, and Tags <http://www.shirky.com/writings/ontology_overrated.html> [2] Pymmetry <http://sourceforge.net/projects/pymmetry> [3] Judgment under Uncertainty: Heuristics and Biases by Daniel Kahneman (Ed), Paul Slovic (Ed), Amos Tversky (Ed) <http://www.amazon.com/Judgment-under-Uncertainty-Heuristics-Biases/ dp/0521284147> [4] Rationality and Reasoning By Jonathan St. B. T., Evans, David E. Over <http://books.google.com/books?id=CzR8pzqsOPEC&dq=%22Evans%22+% 22Rationality+and+Reasoning%22+&psp=9> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iQCVAgUBRXQgilnrWVZ7aXD1AQLcvQP+KEO2mig11QfnUILFvmhJx/u141VEwd6W g5/4nC5SrCBpxcmVryxUzt739RV4ZCqq6B3JMH3kWvMneVy0g4jbFyrq9qttxNsA rDnDsk7/K6TqVnxpzDa3lrld9HcG45DNBD9NdsGYdCMNM4QNffT/dlJGinDOM6BF DAdEeaQAApA= =o06h -----END PGP SIGNATURE----- |
From: Dave B. <da...@br...> - 2006-12-04 02:30:10
|
Graham Higgins wrote: > Hi there, >=20 Welcome, Graham > I jumped through the hoops and now have a konfidi installation up and > running on: >=20 > http://konfidi.bel-epa.com/ Cool! >=20 > What's my next step in exercising the facility? >=20 > For context: I'm investigating konfidi with a view to deploying it > initially in support of an informal group of UK web site developers > and designers who hang out on a private email list. >=20 > There's a degree of general interest amongst the members of the group > in some sort of trust scheme which would facilitate developers > logging on to a site and browsing a list of available designers (and > vice versa) as both persuasions seem to have a need to subcontract > out specialist work outside their skillset. Konfidi hasn't had much application outside of email filtering (and even that has had very limited deployment). It might take some enhancements to Konfidi to meet your use-case. But we would welcome it! The first thing that comes to mind would be that you may want an authentication system other than OpenPGP. OpenID would be my choice in my next webapp >=20 > Additionally, some have expressed a wish to have multiple "domains" > of trust (the usual: "Alice trusts Bob strongly on PHP matters but > weakly on Perl") and they would also like trust to propagate across > members. Konfidi seems to fit the bill. I'm also investigating Yes, topics should work well for that. We haven't implemented support for topic hierarchies, but thats on our wishlist > Pymmetry, I rather like its simple three-valued interval scale, I'm > dubious that a linear ratio scale is appropriate for describing trust > values, I suspect a U-shaped function would be more realistic. I hadn't heard of Pymmetry, I'll look into it. There are some people researching multi-axis trust models, namely Patricia Victor. See http://konfidi.org/wiki/Research Her second axis is consistency/uncertainty. We started with a single 0-1 range for our trust model for simplicity's sake (it could even be interpreted as probabilistic or Bayesian). The interpretation of the 0-1 range is defined by which algorithm is used in the trustserver (they're called TrustStragies there). So you could have an implementation that treats them on a bell curve rather than linearly. As long as the users understand what a 0.8, for example, will mean. >=20 > Konfidi seems to be mostly working (pace a missing 'send_query' > attribute reported on following the "Map all trust relationships and > inferences" link). >=20 A few of those features are probably broken. > An idle query, in the (probably vain) hope of an easy answer: I'm > seeing an "Error: 111, Connection refused", reported for each of the > frontserver test GETs - is that an expected result for a fresh, > unpopulated installation or have I got something wrong? The Frontend is just a web interface to a TrustServer daemon process that does the real work. See the diagram on http://konfidi.org/wiki/Konfidi_System_Design for how it all fits togethe= r. Connection refused means that it's not connecting to the TrustServer process. Looks like we failed to explain that in Server_Setup_Instructions. In the trustserver folder, run =2E/TrustServer.py (the etc/ folder has some scripts that might help you run it as a daemon). Then to populate the TrustServer with some data, run clients/simple/trunk/load_rdf.py in a directory with some .rdf files =2E See http://konfidi.org/wiki/Create_a_FOAF_file for the format it expects. Running load_rdf.py is a quick way to go; an alternative is to set up the FOAFServer (on the same machine) so people can post their own PGP-signed FOAF RDF files. >=20 > Cheers, >=20 > Graham. >=20 --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Graham H. <gjh...@be...> - 2006-12-03 10:19:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I jumped through the hoops and now have a konfidi installation up and running on: http://konfidi.bel-epa.com/ What's my next step in exercising the facility? For context: I'm investigating konfidi with a view to deploying it initially in support of an informal group of UK web site developers and designers who hang out on a private email list. There's a degree of general interest amongst the members of the group in some sort of trust scheme which would facilitate developers logging on to a site and browsing a list of available designers (and vice versa) as both persuasions seem to have a need to subcontract out specialist work outside their skillset. Additionally, some have expressed a wish to have multiple "domains" of trust (the usual: "Alice trusts Bob strongly on PHP matters but weakly on Perl") and they would also like trust to propagate across members. Konfidi seems to fit the bill. I'm also investigating Pymmetry, I rather like its simple three-valued interval scale, I'm dubious that a linear ratio scale is appropriate for describing trust values, I suspect a U-shaped function would be more realistic. Konfidi seems to be mostly working (pace a missing 'send_query' attribute reported on following the "Map all trust relationships and inferences" link). An idle query, in the (probably vain) hope of an easy answer: I'm seeing an "Error: 111, Connection refused", reported for each of the frontserver test GETs - is that an expected result for a fresh, unpopulated installation or have I got something wrong? Cheers, Graham. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iQCVAgUBRXKkuVnrWVZ7aXD1AQLQNwP+PC75JYaIj/kVZ5JsNh60cnSf8xzj8pce dJxtAOtUVTPuIXDAReBK6avawWtz7WZ3m1cYUW1z3GYRAffPMhLAktzbZgfqS9hI z0B43o0bHe0r1ri2cGlldF3qX+k6BEBCtPWvGeWdxVxxLHsG/O7krb7qhqZpcAAV wJ2fOZdN7XY= =uZBu -----END PGP SIGNATURE----- |
From: Dave B. <da...@br...> - 2006-12-02 17:40:03
|
I just blogged http://brondsema.net/blog/index.php/2006/12/02/google_shows_interest_in_s= ocial_trust_ne I added Audun J=F8sang (and L Jean Camp) to http://konfidi.org/wiki/Research. He's got a *lot* of papers that look good. I have only skimmed a few so far though http://sky.fit.qut.edu.au/~josang/ http://sky.fit.qut.edu.au/~josang/papers/JP2005-APCCM.pdf http://sky.fit.qut.edu.au/~josang/papers/JIB2007-DSS.pdf It'd be cool if there were some forum for Internet Trust people to talk, like there are for Internet Identity people (e.g. http://identitygang.org/ http://groups.google.com/group/idworkshop) --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2006-11-21 21:56:25
|
Hmm, it seemed to work this way. And in fact I had to do it because without the #, it wasn't matching the NS that was used in foaf files. Might it have been a different configuration format that did that? We've used a few A. Schamp wrote: > The trailing # in NS name is problematic, because the # character is > treated as a comment and ignored by the config-file parsing thing. I > believe I put some logic once in one of the files to deal with this, bu= t > I don't recall where and don't have the files available now. I don't > know if there's a better way to do it. >=20 > Andy >=20 > On 11/20/06, *bro...@us... > <mailto:bro...@us...>* < > bro...@us... <mailto:bro...@us...>>= > wrote: >=20 > Revision: 582 > http://svn.sourceforge.net/konfidi/?rev=3D582&view=3Drev= > <http://svn.sourceforge.net/konfidi/?rev=3D582&view=3Drev> > Author: brondsem > Date: 2006-11-20 20:39:43 -0800 (Mon, 20 Nov 2006) >=20 > Log Message: > ----------- > use trailing '#' in NS name > misc other minor comments and fixes >=20 > Modified Paths: > -------------- > trustserver/trunk/UpdateListener.py > trustserver/trunk/trustserver.cfg-dist >=20 > Modified: trustserver/trunk/UpdateListener.py > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- trustserver/trunk/UpdateListener.py 2006-11-21 04:24:59 UTC (re= v > 581) > +++ trustserver/trunk/UpdateListener.py 2006-11-21 04:39:43 UTC (re= v > 582) > @@ -55,18 +55,18 @@ > class UpdateListener(SocketServer.BaseRequestHandler ): > def setup(self): > # Create a namespace object for the Friend of a > friend namespace. > - # figure out trailing pound thing... > self.FOAF =3D > Namespace(self.server.trustserver.config.get ("Schema", "foaf_url")= ) > + # FIXME support multiple Konfidi Trust RDF versions= > self.TRUST =3D > Namespace(self.server.trustserver.config.get("Schema", "trust_url")= ) > self.WOT =3D > Namespace(self.server.trustserver.config.get("Schema", "wot_url")) > - self.RDF =3D > Namespace(self.server.trustserver.config.get("Schema", "rdf_url")) > + self.RDFS =3D > Namespace(self.server.trustserver.config.get("Schema", "rdfs_url"))= >=20 > self.log =3D Logger().get_instance(self) > # load trust values into list for later >=20 > #trust.load("http://svn.berlios.de/viewcvs/*checkou= t*/konfidi/schema/trunk/trust.owl#") > #self.trustValues =3D [] > - #for s in trust.subjects(self.RDF["subPropertyOf"],= > self.TRUST["trustValue"]): > + #for s in trust.subjects(self.RDFS["subPropertyOf"]= , > self.TRUST["trustValue"]): > # self.trustValues.append(s) >=20 > def handle(self): > @@ -90,6 +90,7 @@ > count =3D 0 >=20 > for (relationship, truster) in > trust.subject_objects(self.TRUST ["truster"]): > + # FIXME what to do about folks who have > multiple keys? (source and/or sink) > source_pubkey =3D trust.objects(truster, > self.WOT["hasKey"]).next() > source_fingerprint =3D > trust.objects(source_pubkey, self.WOT["fingerprint"]).next() > sink_pubkey =3D > trust.objects(trust.objects(relationship, > self.TRUST["trusted"]).next(), self.WOT["hasKey"]).next() > @@ -103,6 +104,8 @@ > if rating >=3D 0.0 and rating <=3D = 1.0: > self.server.trustserver.net= work.add_edge(source=3Dsource_fingerprint, > sink=3Dsink_fingerprint, subject=3Dtopic, rating=3Drating) > count +=3D 1 > + else: > + self.log.warn("rating out o= f > range [0,1]: " + rating) > self.log.info("Added %d trust links." % count) >=20 >=20 >=20 > Modified: trustserver/trunk/trustserver.cfg-dist > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- trustserver/trunk/trustserver.cfg-dist 2006-11-21 04:24:59= > UTC (rev 581) > +++ trustserver/trunk/trustserver.cfg-dist 2006-11-21 04:39:43= > UTC (rev 582) > @@ -45,12 +45,11 @@ > # See > http://docs.python.org/tut/node8.html#SECTION008110000000000000000 > <http://docs.python.org/tut/node8.html#SECTION008110000000000000000= > >=20 > # provides the URLs of the required XML and RDF schemas, ontologies= , > etc. > -# (won't this be handled by the FOAF server? hmm..) > [Schema] > foaf_url: http://xmlns.com/foaf/0.1/ <http://xmlns.com/foaf/0.1/> > -trust_url: http://www.konfidi.org/ns/trust/1.2 > +trust_url: http://www.konfidi.org/ns/trust/1.2# > wot_url: http://xmlns.com/wot/0.1/ > -rdf_url: http://www.w3.org/2000/01/rdf-schema > +rdfs_url: http://www.w3.org/2000/01/rdf-schema# >=20 > # server variables (port, etc.) > [Server] >=20 >=20 > This was sent by the SourceForge.net collaborative development > platform, the world's largest Open Source development site. >=20 > -------------------------------------------------------------------= ------ > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn c= ash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&= CID=3DDEVDEV > <http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge= &CID=3DDEVDEV> > _______________________________________________ > Konfidi-svn mailing list > Kon...@li... > <mailto:Kon...@li...> > https://lists.sourceforge.net/lists/listinfo/konfidi-svn > <https://lists.sourceforge.net/lists/listinfo/konfidi-svn> >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Konfidi-devel mailing list > Kon...@li... > https://lists.sourceforge.net/lists/listinfo/konfidi-devel --=20 Dave Brondsema Software Developer Cornerstone University |
From: A. S. <sc...@gm...> - 2006-11-21 13:26:59
|
The trailing # in NS name is problematic, because the # character is treated as a comment and ignored by the config-file parsing thing. I believe I put some logic once in one of the files to deal with this, but I don't recall where and don't have the files available now. I don't know if there's a better way to do it. Andy On 11/20/06, bro...@us... <bro...@us...> wrote: > > Revision: 582 > http://svn.sourceforge.net/konfidi/?rev=582&view=rev > Author: brondsem > Date: 2006-11-20 20:39:43 -0800 (Mon, 20 Nov 2006) > > Log Message: > ----------- > use trailing '#' in NS name > misc other minor comments and fixes > > Modified Paths: > -------------- > trustserver/trunk/UpdateListener.py > trustserver/trunk/trustserver.cfg-dist > > Modified: trustserver/trunk/UpdateListener.py > =================================================================== > --- trustserver/trunk/UpdateListener.py 2006-11-21 04:24:59 UTC (rev 581) > +++ trustserver/trunk/UpdateListener.py 2006-11-21 04:39:43 UTC (rev 582) > @@ -55,18 +55,18 @@ > class UpdateListener(SocketServer.BaseRequestHandler): > def setup(self): > # Create a namespace object for the Friend of a friend > namespace. > - # figure out trailing pound thing... > self.FOAF = Namespace(self.server.trustserver.config.get("Schema", > "foaf_url")) > + # FIXME support multiple Konfidi Trust RDF versions > self.TRUST = Namespace(self.server.trustserver.config.get("Schema", > "trust_url")) > self.WOT = Namespace(self.server.trustserver.config.get("Schema", > "wot_url")) > - self.RDF = Namespace(self.server.trustserver.config.get("Schema", > "rdf_url")) > + self.RDFS = Namespace(self.server.trustserver.config.get("Schema", > "rdfs_url")) > > self.log = Logger().get_instance(self) > # load trust values into list for later > > #trust.load(" > http://svn.berlios.de/viewcvs/*checkout*/konfidi/schema/trunk/trust.owl#") > #self.trustValues = [] > - #for s in trust.subjects(self.RDF["subPropertyOf"], > self.TRUST["trustValue"]): > + #for s in trust.subjects(self.RDFS["subPropertyOf"], > self.TRUST["trustValue"]): > # self.trustValues.append(s) > > def handle(self): > @@ -90,6 +90,7 @@ > count = 0 > > for (relationship, truster) in trust.subject_objects( > self.TRUST["truster"]): > + # FIXME what to do about folks who have multiple > keys? (source and/or sink) > source_pubkey = trust.objects(truster, self.WOT > ["hasKey"]).next() > source_fingerprint = trust.objects(source_pubkey, > self.WOT["fingerprint"]).next() > sink_pubkey = trust.objects(trust.objects(relationship, > self.TRUST["trusted"]).next(), self.WOT["hasKey"]).next() > @@ -103,6 +104,8 @@ > if rating >= 0.0 and rating <= 1.0: > > self.server.trustserver.network.add_edge(source=source_fingerprint, > sink=sink_fingerprint, subject=topic, rating=rating) > count += 1 > + else: > + self.log.warn("rating out of range > [0,1]: " + rating) > self.log.info("Added %d trust links." % count) > > > > Modified: trustserver/trunk/trustserver.cfg-dist > =================================================================== > --- trustserver/trunk/trustserver.cfg-dist 2006-11-21 04:24:59 UTC > (rev 581) > +++ trustserver/trunk/trustserver.cfg-dist 2006-11-21 04:39:43 UTC > (rev 582) > @@ -45,12 +45,11 @@ > # See http://docs.python.org/tut/node8.html#SECTION008110000000000000000 > > # provides the URLs of the required XML and RDF schemas, ontologies, etc. > -# (won't this be handled by the FOAF server? hmm..) > [Schema] > foaf_url: http://xmlns.com/foaf/0.1/ > -trust_url: http://www.konfidi.org/ns/trust/1.2 > +trust_url: http://www.konfidi.org/ns/trust/1.2# > wot_url: http://xmlns.com/wot/0.1/ > -rdf_url: http://www.w3.org/2000/01/rdf-schema > +rdfs_url: http://www.w3.org/2000/01/rdf-schema# > > # server variables (port, etc.) > [Server] > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Konfidi-svn mailing list > Kon...@li... > https://lists.sourceforge.net/lists/listinfo/konfidi-svn > |
From: Dave B. <da...@br...> - 2006-11-21 04:50:47
|
One issue I see with the key/value pairs as output from the Frontend are ones like: Path: [u'EAB0FABEDEA81AD4086902FE56F0526F9BB3CE70', u'83097498E8C3B7790C7F9F76B28F65AA1E0CADA8'] That format is too python-ish. It's fine (and good) for the Frontend to get that format from the TrustServer (since they're both python and we don't need to plan for other implementations now). But it's not too good for clients to get that from the Frontend. I'm thinking that we could simply have the Frontend format arrays for output. Not that any Konfidi client is using it yet though :) --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Andrew S. <sc...@gm...> - 2006-11-17 01:24:11
|
It's a function decorator. It's new python syntax, a shortcut for some other form. See: http://pyref.infogami.com/classmethod Andy bro...@us... wrote: > Revision: 577 > http://svn.sourceforge.net/konfidi/?rev=3D577&view=3Drev > Author: brondsem > Date: 2006-11-16 16:22:20 -0800 (Thu, 16 Nov 2006) >=20 > Log Message: > ----------- > Andy, what was this for? my version of python didn't parse it >=20 > Modified Paths: > -------------- > clients/python_module/trunk/Konfidi/Query.py >=20 > Modified: clients/python_module/trunk/Konfidi/Query.py > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- clients/python_module/trunk/Konfidi/Query.py 2006-11-17 00:20:10 UT= C (rev 576) > +++ clients/python_module/trunk/Konfidi/Query.py 2006-11-17 00:22:20 UT= C (rev 577) > @@ -26,7 +26,7 @@ > self.clear() > self.update(d) > =20 > - @classmethod > + #@classmethod > def from_string(cls, str): > # this creates a Query object (or one of its subclasses) from a stri= ng. > # the string provided must have all of the mandatory fields, as defi= ned >=20 >=20 > This was sent by the SourceForge.net collaborative development platform= , the world's largest Open Source development site. >=20 > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Konfidi-svn mailing list > Kon...@li... > https://lists.sourceforge.net/lists/listinfo/konfidi-svn >=20 |
From: Dave B. <da...@br...> - 2006-11-04 00:44:37
|
Tim Berners-Lee likes the concepts of Konfidi (and some specifics of the implementation, like FOAF). Read http://dig.csail.mit.edu/breadcrumbs/node/170 --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |
From: Dave B. <da...@br...> - 2006-10-19 14:38:08
|
A. Schamp wrote: > > > > The trust-o-matic foaf creator, or the foaf server, should have a= > "best > > practices" enforcement option which would require trust > Relationships of > > this type to only use the #email topic (we'd need to implement > > hierarchies). As an aside, it'd also validate that you don't sta= te > > trust in someone who has an OpenPGP key fingerprint to which you = don't > > have a pgp-path. >=20 >=20 > That proposal seems reasonable. It sounds like we should make this > trust-o-matic soon. >=20 I was going to wait until I had more to show, but you brought it up :) See http://brondsema.gotdns.com/~dpb2/jsrdfeditor/ for the beginnings of a generic JavaScript application to create RDF by using OWL schemas. It uses the JS RDF parser from http://www.jibbering.com/rdf-parser/. So far it just reads an OWL schema and pulls some key information from it to display. I decided it would be best to do it as a pure JS app, since everything is web-based these days, and this would allow the editor to be added to any sort of webapp: php, python, RoR, java, etc. Next step in my development on it is obviously to make it have the necessary input fields, and to read/write the RDF file. That URL is actually a Bazaar (http://bazaar-vcs.org/) repository branch. I've been interested in trying a distributed version control system, so I'm doing so with this. I think eventually the generic RDF editor will be flexible enough that a trust-o-matic can hook in to do some Konfidi-particular logic. --=20 Dave Brondsema Software Developer Cornerstone University |
From: A. S. <sc...@gm...> - 2006-10-17 15:32:20
|
Let me reply to all of these at once. Sorry for the delay. I hate being so busy. See my replies in-line. On 10/16/06, Dave Brondsema <da...@br...> wrote: > > If there are no objections to allowing SPF and DKIM to supplement > OpenPGP as sources of authentication, I'm going to move towards this > goal. I'll do it incrementally, and post my progress to the list. I don't object. See below. Splitting cli-filter into PGP-auth-validator and > konfidi-trust-client-thingie, and refactoring into SpamAssassin modules > will be the first step. And conceptually, I like the idea of having the > final konfidi trust-value be a (very strong) input into the S.A. scoring > system. That way, if there is a trust rating that is > middle-of-the-road, some positive or some negative scores from other SA > rules will help tip the balance of determining if that email is spam or > not. Interoperability would help early adoption. Dave Brondsema wrote: > > Dave Brondsema wrote: > >> http://konfidi.org/wiki/Konfidi_Compared#DomainKeys_Identified_Mail > >> > >> I think we should support this. > >> > > > > First, think about identity, authentication, and trust as separate > concepts. > > > These are different patterns of identity & trust. SPF uses a pattern > > similar to that of DKIM. I think Konfidi can support them all. > > > > OpenPGP identities are generated fingerprints; one per agent (person, > > normally). Trust in the identity is achieved by having a path of signed > > keys from source to sink identity. Auth is done by validating a > > signature that comes from one of they subkeys on the identity's primary > > key. (Konfidi) Trust is declared from an agent having a certain OpenPGP > > fingerprint to another agent having a certain OpenPGP fingerprint. > > > > DKIM identities are email addresses. Auth is done by validating an > > email's DKIM signature with the DKIM public key that is found in DNS in > > a hostname related to the email address's domain. That key may be used > > for a range of email addresses (e.g. "*@domain.com"), and the key may > > change frequently (it is only guaranteed to exist long enough for > > regular email transit and verification). Trust in the identity is > > inherent, given trust in DNS. (Konfidi) Trust would be declared from > > an agent having a certain OpenPGP fingerprint to a email address > > pattern. This would always be an ending edge in a trust path (i.e. the > > trusted email addresses can't somehow say that they trust somebody > else). > > > > There is a risk that the registration for a trusted domain will expire, > > and a spammer will acquire the domain and set up a new valid DKIM > > infrastructure there. This would apply to trusting in SPF, also. I > > think this is a risk that will have to be taken for those who wish to > > use DKIM and SPF in Konfidi. Watching for changes in WHOIS records or > > DNS records could provide some heuristics, but I don't feel it'd even be > > worth implementing. > > > > SpamAssassin already has plugins for DKIM and SPF whitelisting, by email > > address (patterns): > > > http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Plugin_DKIM.html > > > http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Plugin_SPF.html > > email address pattern syntax at > > > http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#whitelist_and_blacklist_options > > I find no evidence that the above risk has been addressed. > > > > Here's my proposal: > > > > People using OpenPGP may declare their trust in an email address or > > email address pattern in their foaf file. > > <Relationship> > > <truster rdf:nodeID="EAB0FABEDEA81AD4086902FE56F0526F9BB3CE70"/> > > <trusted> > > <foaf:Agent> > > <!-- perhaps for mbox _patterns_ we should have a new > > predicate --> > > <foaf:mbox>*@yahoo-inc.com</foaf:mbox> > > </foaf:Agent> > > </trusted> > > <about> > > <Item> > > <topic rdf:resource="&topics;#email"/> > > <rating>.9</rating> > > </Item> > > </about> > > </Relationship> > > > > > > The trust-o-matic foaf creator, or the foaf server, should have a "best > > practices" enforcement option which would require trust Relationships of > > this type to only use the #email topic (we'd need to implement > > hierarchies). As an aside, it'd also validate that you don't state > > trust in someone who has an OpenPGP key fingerprint to which you don't > > have a pgp-path. That proposal seems reasonable. It sounds like we should make this trust-o-matic soon. This aside seems like a good solution to a question that's been bugging me for some time. It is necessary to confirm that a valid signature path exists from the source to each node in the chosen path to the sink, otherwise, inserting a spoofed record in the middle of the chain might work. However, if PGP links are verified for each FOAF as they are added to the system, then it follows that any trust path that can be found from any source to any sink also has at least one PGP link. Thus, if this could be inforced at input time (maybe at trust-o-matic level, perhaps at FOAFServer level or discovery-crawl-time, or whenever it gets into the TrustServer), it wouldn't have to be re-computed/checked for every query. (something similar could be done for DKIM/SPF Konfidi links) > Trustserver internals would have to be modified to support this, > > obviously. For queries to the trustserver, the source parameter would > > always be a OpenPGP fingerprint. The sink parameter could be either an > > OpenPGP fingerprint or a mbox pattern. These could be automatically > > distinguished currently, but in the consideration of new future > > identifiers, I think we should use URI identifiers. > > mailto:*@yahoo-inc.com and > > urn:pgp:EAB0FABEDEA81AD4086902FE56F0526F9BB3CE70: (see expired > > draft-swartz-pgp-urn-00) > > > > Konfidi client implementation would be split into two parts: > > authenticators and trust checker. The different authenticators would: > > * validate an OpenPGP signature (including querying the PGP pathfinder) > > * validate a DKIM signature > > * validate SPF records > > And would not necessarily be part of Konfidi proper (e.g. the existing > > SpamAssassin plugin for DKIM) > > Then the trust checker would then use the identities provided by the > > authenticator(s) to do a TrustServer query to get the computed trust > > value of the sender. The trust checker would be configurable with > > regard to which identities it would use (e.g. some might not want to > > consider SPF authenticity) and the precedence (e.g. what to do if there > > is a OpenPGP signature and a DKIM signature). That sounds complicated, but it ought to work. > This would make some significant changes to the architecture of Konfidi > > as a whole, but I think it would be good. I like having authentication > > and trust more clearly separated. Yes, as shown above, it opens the door for integrating different strategies as they are discovered/developed. I think it's good to try and keep things open and flexible and loosely-coupled. In related news, I've been studying graph and tree search in my AI class, and cringing everytime I think of the complexity of breadth-first-search. I don't know when I'll have time to work on it, but I want to explore a different framework for search strategies, which would allow interchangeable search strategies, cost evaluation, and so forth, with callbacks for computing edge cost, etc. It would also be good to have a corpus of test-data to do some time-analysis to see how acceptible the algorithms really are. Andy |
From: Dave B. <da...@br...> - 2006-10-16 21:53:05
|
We've said that you should verify the identity of a PGP keyholder by having a path of PGP key signatures from you to the keyholder in question. And that this should be done before computing konfidi-trust on a particular document, and also before stating trust in that person in your foaf file. However, I have a real case that would suggest a different way to know the identity of a PGP keyholder. I use joker.com as my domain registrar. Their emails a PGP signed, but I have no path from me to them. But I do know their identity of the agent holding PGP key 8EC2 887F C814 D60D 73A9 B1D5 26DD E134 1144 E223, because of the communication I have already received that has been signed by that key. PGP pathfinding is already optional at the trustserver, and it's not implemented as a "best practice" warning at the foafserver yet. So no real impact .. just a thought. --=20 Dave Brondsema : da...@br... http://www.brondsema.net : personal http://www.splike.com : programming <>< |