1. 01 Jan, 2002 2 commits
  2. 31 Dec, 2001 1 commit
  3. 30 Dec, 2001 1 commit
  4. 29 Dec, 2001 1 commit
  5. 28 Dec, 2001 1 commit
  6. 26 Dec, 2001 3 commits
  7. 23 Dec, 2001 2 commits
  8. 22 Dec, 2001 1 commit
  9. 17 Dec, 2001 1 commit
  10. 10 Dec, 2001 1 commit
  11. 09 Dec, 2001 1 commit
  12. 06 Dec, 2001 4 commits
  13. 05 Dec, 2001 4 commits
  14. 04 Dec, 2001 2 commits
  15. 02 Dec, 2001 1 commit
  16. 17 Nov, 2001 1 commit
  17. 16 Nov, 2001 1 commit
  18. 09 Nov, 2001 1 commit
  19. 07 Nov, 2001 1 commit
  20. 06 Nov, 2001 2 commits
  21. 05 Nov, 2001 1 commit
  22. 03 Nov, 2001 1 commit
  23. 23 Oct, 2001 2 commits
  24. 22 Oct, 2001 2 commits
    • Julio Sánchez Fernández's avatar
      be89c094
    • Julio Sánchez Fernández's avatar
      It now sort of works, but needs some normalization work and proper · 7581e304
      Julio Sánchez Fernández authored
      error reporting to client and syslog. And indexing, of course.
      
      Now, the problem is that matching rules get called from different
      places that are inconsistent in what an assertedValue is.  When doing
      a modify, a full certificate value is passed (to verify it isn't
      already there).  When doing a search or compare, the passed value is
      in the syntax of the matching rule.
      
      Consistency would require that the caller extracts an asserted value
      from the full value before calling smr_match.  It can do this by
      calling smr_convert (it was unused, was it meant to be used for
      this?).
      
      Unfortunately, the caller is typically value_find, value_match, etc.
      that have themselves little knowledge of what they are dealing with,
      so their interface needs to be extended, new flag values or new
      arguments, so that they know if they have a value in attribute type
      syntax or in matching rule syntax.
      7581e304
  25. 20 Oct, 2001 2 commits