fusiondirectory issueshttps://gitlab.fusiondirectory.org/groups/fusiondirectory/-/issues2022-09-01T09:27:38Zhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6112change the donate part to add all the crowfunding possibilities2022-09-01T09:27:38Zbmortierchange the donate part to add all the crowfunding possibilitieshello,
we need to replace the donate with all our crowfunding possibilities
Cheershello,
we need to replace the donate with all our crowfunding possibilities
CheersFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6137XSS in management filters2022-09-01T09:02:20ZbmortierXSS in management filtersI found a cross site scripting issue in FusionDirectory. You can
easily reproduce the issue with the following procedures:
1. Launch FusionDirectory 1.2.1
$ git clone https://github.com/hrektts/docker-fusiondirectory.git
$ docker-compo...I found a cross site scripting issue in FusionDirectory. You can
easily reproduce the issue with the following procedures:
1. Launch FusionDirectory 1.2.1
$ git clone https://github.com/hrektts/docker-fusiondirectory.git
$ docker-compose up -d
2. Open http://localhost:10080/fd/ with the Browser
3. Enter fd-admin / fdadminpwd to sign in
4. Go to "users" in the left menu
5. Input "et7s7'onfocus='alert(1)'autofocus='laqnc" to a textfield in
Filter on the right side
This issue might remain in the latest version. For fixing this issue,
the user input must be escaped properly.
Regards,
TakumiFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6136Weak random generator use in fusiondirectory-setup2022-09-01T08:59:53ZbmortierWeak random generator use in fusiondirectory-setupÀ l'occasion d'une installation de Fusion Directory, j'ai vu qu'on
pouvait chiffrer le mot de passe d'accès au serveur LDAP.
Le script qui fait cela dans fusiondirectory-1.3 est
(contrib/bin/fusiondirectory-setup) tire une clé à l'aide ...À l'occasion d'une installation de Fusion Directory, j'ai vu qu'on
pouvait chiffrer le mot de passe d'accès au serveur LDAP.
Le script qui fait cela dans fusiondirectory-1.3 est
(contrib/bin/fusiondirectory-setup) tire une clé à l'aide de la
fonction get_random_string, définie à partir de la ligne 228 :
```
sub get_random_string {
my ($size) = @_;
$size = 32 if !$size;
my @chars = ("A".."Z", "a".."z", '.', '/', 0..9);
my $string;
$string .= $chars[rand @chars] for 1..$size;
return $string;
}
```
La fonction utilisée pour cela est rand (ligne juste au-dessus du
return). Comme le dit la documentation de rand
(https://perldoc.perl.org/functions/rand.html) :
> rand is not cryptographically secure. You should not rely on it in
> security-sensitive situations. As of this writing, a number of
> third-party CPAN modules offer random number generators intended by
> their authors to be cryptographically secure, including:
> Data::Entropy, Crypt::Random, Math::Random::Secure, and
> Math::TrulyRandom.
Le problème est que le résultat d'une fonction comme rand peuvent
relativement aisément se deviner. La vulnérabilité est ici
relativement mineure mais je vous suggère de corriger car cela n'est
pas très difficile : il suffit de faire appel à la fonction Random du
module Crypt, déjà utilisé dans ce script.
Cela dit :
- Je ne suis pas certain d'avoir bien compris toutes les implications
de ce chiffrement et de l'utilisation du module header d'apache pour
transmettre la clé de chiffrement à l'application. Est-ce que l'idée
est de résister à une faille qui permettrait de faire de la lecture
de fichiers arbitraires avec les droits du serveur mais pas de lire
les entêtes HTTP ?
- Dans tous les cas, stocker le mot de passe LDAP (chiffré ou non)
n'est pas l'idéal en terme de sécurité (c'est plutôt une
vulnérabilité importante) ; idéalement, c'est le mot de passe entré
par l'utilisateur de Fusion Directory qui devrait être utilisé
auprès du serveur LDAP et les droits devraient être gérés au niveau
du serveur LDAP. J'ai l'impression que ce n'est pas ce qui a été
fait mais j'imagine que c'est assez difficile à modifier après coup.
- Merci pour ce projet et merci d'en avoir fait un logiciel libre !
(Je l'ai découvert en aidant une association à monter son serveur
LDAP)
Très cordialement,
Judicaël Courant.FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6103Unable to change template name or create template2022-09-01T08:11:45ZbmortierUnable to change template name or create template### Description
After given the correct (I'm guessing) ACL to person to modify user templates, those person can modify indeed all template. But the user cannot modify the name of the template (that's minor bug). They are no error messag...### Description
After given the correct (I'm guessing) ACL to person to modify user templates, those person can modify indeed all template. But the user cannot modify the name of the template (that's minor bug). They are no error message, if the person change the name, he can save. But nothing actually change. The name still the old one.
More inconvenient the person cannot create a a template, He got the menu to create a template, he is invited in the tab to create a template, and what ever you name the template, FD say thay are a conflict with some other tempate whos name a nothing to do with the name the person choose, it's even not in the same branch.
Don't know where the problem are. Maybe in the ACL because as super_admin everything work. But because the person can modify anything in the model...
### Distribution Name and Version
Debian 9.12
### FusionDirectory Version
1.3
### PHP version used
7.0.33
### Origin of php packages
Distribution packages
### Steps to Reproduce
1. Select a modele
2. Change the name
3. Save the template
4. Check the name
1. Select Action/Add/Model
2. Enter anything in the name
3. Save
**Expected behavior:**
The name are change.
The template are created
**Actual behavior:**
The name still the same/
Got some strange error about conflict name
**Reproduces how often:**
100%FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd-plugins/-/issues/6182make all docker images come from the /fd registry2022-07-28T18:29:38Zbmortiermake all docker images come from the /fd registry## Descriptive title for this enhancement
make all docker images come from the /fd registry
<!-- required -->
### Actual behavior
some images come from the fd-plugins registry, it make no sense to have twice the same images
<!-- Wha...## Descriptive title for this enhancement
make all docker images come from the /fd registry
<!-- required -->
### Actual behavior
some images come from the fd-plugins registry, it make no sense to have twice the same images
<!-- What actually happens -->
### Expected behavior
ci is using images from /fd
<!-- What you expect to happen-->
### Benefits
all images come from the same registry
<!-- optional -->
<!-- What benefits will be realized by the code change? -->
### Possible Drawbacks
none
<!-- optional -->
<!-- What are the possible side-effects or negative impacts of the code change? -->FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/dev-manual/-/issues/52replace freenode by libera2022-06-09T20:30:52Zbmortierreplace freenode by liberahello,
we are now on libera but the manual still say freenode, we must correct this
Cheershello,
we are now on libera but the manual still say freenode, we must correct this
CheersFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6003Fatal error after using search box filter2022-02-11T19:08:20ZbmortierFatal error after using search box filter### Description
On a fresh install of FD, against an empty OpenLDAP (except for root dc), after setting up the application, users have sometimes an unrecoverable fatal error (they have to log out and back in to revover UI) :
```
Fatal ...### Description
On a fresh install of FD, against an empty OpenLDAP (except for root dc), after setting up the application, users have sometimes an unrecoverable fatal error (they have to log out and back in to revover UI) :
```
Fatal error: Uncaught Exception: Unknown element type specified: ! in /usr/share/fusiondirectory/include/class_filter.inc:420
Stack trace:
#0 /usr/share/fusiondirectory/include/class_listing.inc(486): filter->render()
#1 /usr/share/fusiondirectory/include/simpleplugin/class_simpleManagement.inc(537): listing->render()
#2 /usr/share/fusiondirectory/plugins/admin/users/class_userManagement.inc(119): simpleManagement->renderList()
#3 /usr/share/fusiondirectory/include/simpleplugin/class_simpleManagement.inc(609): userManagement->renderList()
#4 /usr/share/fusiondirectory/include/simpleplugin/class_simpleManagement.inc(1356): simpleManagement->execute()
#5 /usr/share/fusiondirectory/plugins/admin/users/main.inc(21): simpleManagement::mainInc('userManagement')
#6 /usr/share/fusiondirectory/html/main.php(284): require('/usr/share/fusi...')
#7 {main} thrown in /usr/share/fusiondirectory/include/class_filter.inc on line 420
```
We are able to reproduce it each time by filtering with the search box filter in users management, then opening another menu item in "users and groups" section, and then coming back to user management. The error occurs on this last step.
### Distribution Name and Version
Reproduced on Debian Stretch and Ubuntu 16.04
### FusionDirectory Version
1.3-1
### PHP version used
PHP 7.0.33-0+deb9u3
### Origin of php packages
debian
### Steps to Reproduce
1. Open user management
2. Type some text in search box filter
3. Clic on "Apply filter"
4. Navigate to another menu item (such as "Group and roles")
5. Navigate back to user management
6. White page is displayed with following message : "Fatal error: Uncaught Exception: Unknown element type specified: ! in /usr/share/fusiondirectory/include/class_filter.inc:420 ..." (see description for complete message)
7. UI is broken until user log back in.
**Reproduces how often:**
100%; though,
### Additional Information
Do not occur with PHP 5.
Similar issue was found (#5862), but it looks the bug wasn't actually fixed.
Plugins used : ldapdump ldapmanager mail dsa ppolicyFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/user-manual/-/issues/178replace freenode by libera2021-09-02T12:56:27Zbmortierreplace freenode by liberahello,
we are now on libera but the manual still say freenode, we must correct this
Cheershello,
we are now on libera but the manual still say freenode, we must correct this
CheersFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd-plugins/-/issues/6079reload dns map from dns interface didn't work , but from server it works2021-08-25T18:45:50Zagallavardinreload dns map from dns interface didn't work , but from server it works### Description
Try to reload map from DNS main interface : it didn't work :
![image](/uploads/3815761c91542eced7436083e7648667/image.png)
I add a data::dumper trace on Argonaut client :
```
Nov 11 16:22:39 [NOTICE] ldap2zone called zo...### Description
Try to reload map from DNS main interface : it didn't work :
![image](/uploads/3815761c91542eced7436083e7648667/image.png)
I add a data::dumper trace on Argonaut client :
```
Nov 11 16:22:39 [NOTICE] ldap2zone called zone: $VAR1 = [
'demo.fusion.'
];
```
Try to reload from serveur view : it's work
![image](/uploads/18dd67beb8123ede21958d8c002a11ea/image.png)
Trace from argonaut client :
`Nov 11 16:31:16 [NOTICE] ldap2zone called zone: $VAR1 = 'demo.fusion.';`
see the difference : from DNS main interface, an array is sent, from server interface it's a string
### Distribution Name and Version
Debian Stretch
### FusionDirectory Version
from git
```
root@fd-14-dev:/usr/local/src/fd-plugins# git show
commit 573c517c78477d75d3a32d3961a3a8c6156fa938 (HEAD -> 1.4-dev, origin/HEAD, origin/1.4-dev)
```
### Plugin with the defect
dns
### PHP version used
`ii php7.3 7.3.19-1~deb10u1 `
### Steps to Reproduce
1. create a single dns zone
2. reload it from DNS main interface : FAIL
3. reload it from DNS tab in Server main interface : WORKS
**Reproduces how often:**
100%FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6122Problems with FD web setup2021-08-25T18:13:38ZbmortierProblems with FD web setupThe «Installation check» page fails to load checks at first load, and only shows two empty warning checks.
Also the right section shows «PHP setup configuration (<a href="?info" target="_blank">show information</a>)» as title, the html ...The «Installation check» page fails to load checks at first load, and only shows two empty warning checks.
Also the right section shows «PHP setup configuration (<a href="?info" target="_blank">show information</a>)» as title, the html link is escaped.FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd-plugins/-/issues/5825LDAP error in audit plugin2021-07-30T12:35:49ZCôme ChillietLDAP error in audit pluginAudit plugin sometimes trigger an LDAP error "Other", which seems to be related to a limit of RDN length.
So we may need to add some kind of random id to avoid having too long DNs for audit events.Audit plugin sometimes trigger an LDAP error "Other", which seems to be related to a limit of RDN length.
So we may need to add some kind of random id to avoid having too long DNs for audit events.FusionDirectory 1.3.1Côme ChillietCôme Chilliethttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/5995Audit events DN are too long2021-07-30T12:34:23ZbmortierAudit events DN are too longRelated to fd-plugins#5825
Audit events do not include fdAuditId because create_unique_dn only accepts string values.
Also, having the microseconds it the timestamp would be good because it gives more information (especially order of e...Related to fd-plugins#5825
Audit events do not include fdAuditId because create_unique_dn only accepts string values.
Also, having the microseconds it the timestamp would be good because it gives more information (especially order of events) and helps having unique DNs.FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/user-manual/-/issues/171FusionDirectory < 1.4 is not compatible with PHP>=82021-07-14T14:15:04ZCôme ChillietFusionDirectory < 1.4 is not compatible with PHP>=8It should appear in the documentation that maximum PHP version for 1.3.x is PHP 7.4.
it should be placed in the https://fusiondirectory-user-manual.readthedocs.io/en/1.3/fusiondirectory/prerequisite/prerequisite.html#phpIt should appear in the documentation that maximum PHP version for 1.3.x is PHP 7.4.
it should be placed in the https://fusiondirectory-user-manual.readthedocs.io/en/1.3/fusiondirectory/prerequisite/prerequisite.html#phpFusionDirectory 1.3.1Côme ChillietCôme Chilliethttps://gitlab.fusiondirectory.org/fusiondirectory/user-manual/-/issues/174A lot of schema path are wrong2021-07-14T14:00:50ZCôme ChillietA lot of schema path are wrongChecking a few plugins shows that there are a lot of mistakes between /etc/ldap and /etc/openldap.
* Alias
* Applications
* Archive
* Audit
* Autofs5
* Cyrus
* debconf
* dsa
* gpg
* ipmi
* mailinblack
* migration-mailrouting
* newslette...Checking a few plugins shows that there are a lot of mistakes between /etc/ldap and /etc/openldap.
* Alias
* Applications
* Archive
* Audit
* Autofs5
* Cyrus
* debconf
* dsa
* gpg
* ipmi
* mailinblack
* migration-mailrouting
* newsletter
* nextcloud
* personal
* renater-partage
* schac
* subcontracting
* webauthn
* weblink
* zimbraFusionDirectory 1.3.1Côme ChillietCôme Chilliethttps://gitlab.fusiondirectory.org/fusiondirectory/user-manual/-/issues/55ACL documentation should state that write implies read2021-07-14T08:59:23ZCôme ChillietACL documentation should state that write implies readIf a user is allowed to write a field, FD silently allows him to read it as well.
This may be obvious to some people but it would be better if this was clearly stated by the documentation.If a user is allowed to write a field, FD silently allows him to read it as well.
This may be obvious to some people but it would be better if this was clearly stated by the documentation.FusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/dev-manual/-/issues/1adding release policies2021-07-12T14:14:38Zbmortieradding release policiesHello,
we need the explanations of releases policies in our dev documentationHello,
we need the explanations of releases policies in our dev documentationFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/dev-manual/-/issues/2adding license2021-07-12T14:14:05Zbmortieradding licensehello,
we need a license explaining what is the license of documentation and FusionDirectory
Cheershello,
we need a license explaining what is the license of documentation and FusionDirectory
CheersFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/dev-manual/-/issues/3reorganising logically the documentation2021-07-12T14:13:43Zbmortierreorganising logically the documentationHello,
i'm reorganizing the documentation to have everthing in folders and minimal files at the top
CheersHello,
i'm reorganizing the documentation to have everthing in folders and minimal files at the top
CheersFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/dev-manual/-/issues/4Adding more documentation2021-07-12T14:13:22ZbmortierAdding more documentationHello,
putting latest missing documentation :
copyright headers
api
webservice
CheersHello,
putting latest missing documentation :
copyright headers
api
webservice
CheersFusionDirectory 1.3.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/dev-manual/-/issues/5adding code of conduct2021-07-12T14:12:58Zbmortieradding code of conductFusionDirectory 1.3.1bmortierbmortier